We moved from on-premises to a private cloud.
Only our ERP admins use this solution, so it's about five people.
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.
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.
I've been using this solution for three years.
The stability is good. It's very reliable.
The scalability is good. If we want to add more databases, we are able to do it without any issues.
The initial solution we used was a basic solution that involved manually copying the logs from the primary to the secondary site, and there was no automation.
Initial setup is of medium difficulty if you know how to use Oracle Data Guard. Implementation took three days.
Implementation was done in-house. We only had a maximum of three people deploying the solution.
The cost is expensive.
I would rate this solution 10 out of 10.
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.
We have a couple of Oracle systems that are attached to different types of applications.
In terms of Data Guard, we use it for factory monitoring.
We like Oracle because the solution is very robust. It's also efficient for queries and is easy to scale.
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.
The stability of the solution is good.
The scalability of the solution is good. We have roughly 1,000 users right now.
Technical support is very good. If at any time we write a ticket, we get the appropriate answer on time.
The set is straightforward but it is dependent on the audience you have. Internally, we have experienced DBAs, so deploying Oracle is straightforward. If we had to do the same job for an external company it could be complex.
Previously we were doing the set up ourselves. Now, for more than a decade, we work with a third party, and we delegate the deployment, the support, and the maintenance of the Oracle Database.
The pricing of Oracle is average. It's not inexpensive but it's okay.
Currently, we are using the on-premise version on the solution.
I would rate this solution eight out of ten. I would recommend the solution because it is a good product and it's working fine. But I'm not sure if it's suitable for every consideration or any environment.
We primarily use the solution to have the peer site and a copy of it available in our global data center.
The installation process is straightforward.
The solution is stable and the performance is good.
The solution can scale as needed.
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.
We've used the solution for eight to ten instances. It's been a few years.
The performance and stability are great. It doesn't crash or freeze. I find it to be a reliable product.
I would say that the solution is scalable. If a company needs to expand it, it can do so.
We have about 3,000 users on the solution right now.
The initial setup is not overly difficult. It's not complex. It's very easy, very straightforward.
I cannot recall the exact amount of time the actual deployment took.
We have some engineers that can handle the setup process. We have eight or nine that can handle deployment or maintenance tasks.
We pay a yearly licensing fee to Oracle.
I also looked at MySQL as a potential option before choosing this solution.
I'd rate the solution at a five out of ten. We've recently had some issues and aren't very satisfied with it right now.
At this point, I would not recommend it to others. It might be too buggy for most people.
Data focus is the main issue. Most of the features of a new database still go to an Oracle administration section.
The monitor can predict if you have any issues or develop actions to find a solution for them.
We use the product for data recovery.
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.
Oracle Data Guard is stable, but you need to keep monitoring the system all the time. You need to keep monitoring the archives. If some of the archives have been deleted, you need to do it manually. It is a lot of work pressure and a lot of monitoring.
You need to do the dummy work every day just to ensure that Oracle Data Guard is working at the point when you need it.
Scalability with Oracle Data Guard is not straightforward, i.e. the configuration.
We use two different kinds in that case of data guard. You cannot keep looking at the overhead of the projection servers. Oracle Data Guard should know what you are doing. This is the problem. For migrations, it can be a long time.
For Oracle tech support, you do it yourself. When you open a ticket, it can take time to solve it. Often you can find a bug that went unreported.
The initial setup is straightforward. Just follow the documentation. For our present situation, it was dependent on the project and the database files.
Sometimes the setup took one day, sometimes only one hour. It was depending on the size of the database. It could be very fast for me.
I did the implementation of Oracle Data Guard by myself.
Oracle Data Guard is a free solution. When you apply for Enterprise Manager, it comes for free with the solution. When you apply an enterprise solution to a database, you have to pay. It depends on the connotation of the project and what you need for the protocol.
Keep monitoring. This is the problem with the product. You have to keep monitoring the system all the time, just to avoid the interruption from the archive mode.
I am going to give Oracle Data Guard a seven out of ten. It still needs improvements. When you are doing the troubleshooting there are no monitoring tools. You have to keep watching the log all the time. Also, for the configuration, if you miss one of the backlogs, you have to re-issue again. Re-issuing is not easy. It's a long process to do it.
The deployment cost is expensive.
I have been using the product for ten years.
Oracle Data Guard is scalable. I rate it a ten out of ten.
I use Oracle Data Guard as a DR (disaster recovery) solution. Usually, I use the free license Data Guard, which is called the physical Data Guard.
Oracle Data Guard has a nice feature called the DataGuard snapshot to open the solution in the read-write mode and make some changes to the database. When you finish your work, you can do a rollback to the point that you started the snapshot and continue working.
Sometimes, the technical support team takes time to respond.
I have been using Oracle Data Guard for ten years.
I rate Oracle Data Guard a nine out of ten for stability.
I rate Oracle Data Guard a nine out of ten for scalability.
Sometimes, the technical support team responds quickly; other times, they take time to respond. Usually, the first response or action from the Oracle site on my service request is rapid.
The solution’s initial setup is straightforward.
The solution's deployment time may vary according to factors like the database, storage, size, network facilities, and security. On average, the deployment takes three days.
Oracle Data Guard provides DR and acts as a high-availability solution in case of a crisis in the primary database.
Overall, I rate Oracle Data Guard a nine out of ten.
We use it for application disaster recovery. It is deployed on-prem, and one side is our side, and the second side is Microsoft Azure.
Backup and application continuity are most valuable.
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.
I have been working with this solution for the last two years.
If one is most stable, I'd rate it a two out of five. We were facing some issues. It isn't something that you set up and then go to sleep for two years. We have to maintain it and tweak it several times, but it is still very good in terms of stability.
It is very scalable and reliable.
I would rate it a two out of five. It is not very good. There are a lot of community guides, but Oracle documentation is not straightforward, specifically when you use one site as the cloud site and one site as your on-prem site. If one is the best, in the cloud arena, I would rate them a two out of five. There is some community support, and there is some Oracle support, but they still have room to improve.
It was complex. My DBA had a difficult time. If five represents the most complex, I would rate it a five out of five in terms of complexity.
It required multiple experts. It required Microsoft support, our own system experts, and an external DBA to make the transition work. It took us two weeks to move from one Data Guard replication to another Data Guard replication.
It is not a cheap product, but if you look at the price, features, availability, scalability, and maturity, it is a very good product.
Involve Oracle as early as you can and do a version upgrade to the latest DB version before you try to migrate to the cloud. First, do all the migrations that you need to do locally in your Oracle database, and only after that, do a cloud migration.
I would rate it an eight out of 10. It is quite reliable, but there are problems. It is not perfect. There is a monopoly of technology, and this is the only cost-sensitive product around. The other products are either very expensive or not reliable.
I don't quite agree with "you have to keep monitoring the system all the time". Monitoring is just part of any Oracle database or system. You implement monitoring of your databases with Cloud Control and that automatically includes Data Guard monitoring. If you define your monitoring templates and incident rules in Cloud Control appropriately, the monitoring work will all be done by Oracle, not you. You can configure Cloud Control to send a mail to you whenever there a Data Guard problem, or have an incident created, or have a text sent to DBA team, or a corrective action fired, etc. Monitoring should not be a burden! However, troubleshooting DG whenever there is a problem can be more tricky. But most of time a simple "disable configuration; enable configuration;" solves synchronization problems.
We created an interactive script to create a Data Guard. Therefore, the time required to create a DG is roughly the time needed to clone the primary database. The script does everything, including changing files tnsnames.ora, listener.ora, etc. Invest some time in scripting and creating Data Guard databases will become as easy as creating a standalone database.