Q.003: Can I use fewer CPUs on Data Guard Standby to save costs?

Q.003: Can I use fewer CPUs on Data Guard Standby to save costs?

This article is part of a series of short blogs answering your common questions about Oracle Database Cloud services.

One of the most beneficial cloud features is scalability on-demand, paying only for what you use, and releasing the resources when not needed anymore. So the question is, could I configure the standby database to use fewer CPUs than the primary to save costs?

Yes, BUT... you have to consider a few things!

No alt text provided for this image

Oracle Cloud provides an automated way to set up a Data Guard configuration by the click of a button. For example, for DBCS VM, choose a smaller shape on the "Enable Data Guard" page when you initiate the process. Keep in mind that the shape you choose also determines the network bandwidth and IOPS you get.

No alt text provided for this image

For DBCS Bare Metal or ExaCS, you would just enable fewer OCPUs on the standby side. Anyway, you'd have to consider the following:

Workload on Primary and Standby

Every transaction on the primary is replayed on standby. Your standby database (even if only in the mounted state) should be able to handle the workload coming from the primary. If this is not the case, and you run in SYNC mode, you'd encounter a delay in transaction commits on the primary. In the case of ASYNC, the lag between primary and standby could get bigger because the redo apply performance is too slow on the standby side.

If you are using Active Data Guard, consider the additional workload resulting from the Read-Only statements on standby.

Switchover

Before switchover, you'd need to make sure that the current standby runs with more resources now. This is not critical, as it does not affect the availability of the primary. For DBCS VMs, changing the shape is an offline operation, so the primary is not protected during the "change shape" process. But I think you could live with that in most cases.

No alt text provided for this image

Failover

The failover case is more critical. Here, you'll need to scale up the primary database. In the case of DBCS Bare Metal or ExaCS, scaling up is an online operation, but you still have to think about doing it.

No alt text provided for this image

However, changing the shape of a DBCS VM requires downtime, which would count to your RTO. Also, do you want to do such an operation on your primary while your standby (the older primary) is actually broken?

If you are using RAC, then the change shape operation takes place in a rolling fashion, allowing you to change the shape with no database downtime.

Summary

Assign enough resources to your standby to handle the traffic coming from the primary. For DBCS Bare Metal or ExaCS scaling up and down is an online operation and is done easily. Changing the shape of a virtual machine requires downtime that you might not have after a failover. Using RAC eliminates the downtime needed for the change shape operation.

In the end, Disaster Recovery is about ensuring high availability and saving your data, not saving money.

Do you have any further questions or experiences? Please feel free to share them in a comment or sending me a private message.

Thank you for reading!

Claus Jandausch

Senior Sales Manager Public Services State & Local bei Oracle

4 年

Is there RAC on bare metal??

回复
Mohammed Anzar khan

Architect (DB Specialist) at Persistent Systems|H1-B USA Visa petition Approved | Oracle DBA||MongoDB/CassandraDB DBA|Azure Cloud Migration (IaaS/PaaS/SaaS)|Oracle@Azure DB|MS SQL | MySQL|PostgreSQL|Linux.

4 年

Thanks for sharing

回复
Shadab M.

Master Principal Cloud Architect @ Oracle | Oracle Cloud, Exadata, PostgreSQL, MySQL, Database Migrations

4 年

RAC on VMDB can change shape without downtime in a rolling fashion https://docs.cloud.oracle.com/en-us/iaas/Content/Database/Tasks/managingDBsystem.htm

  • 该图片无替代文字
回复
Peter S.

Oracle | Exadata | OCI | Ansible Ak chce? zmenu, zmeň seba ????♀?

4 年

If scaling CPU is possible, there is no need to pay these additional $$, it's possible to wait for FAN events and based on them using oci cmd we could trigger a scale operation.. the question here is if it's faster than a failover or switchover.

回复
Simo Vilmunen

Oracle Cloud Infrastructure, Multi Cloud & Exadata Cloud Practice Director @ Accenture Enkitec Group | Oracle ACE

4 年

Nice article! I think yesterday there was new feature with DBCS RAC VM scaling so no complete downtime required anymore - that's great news!

要查看或添加评论,请登录

Sinan Petrus Toma的更多文章

社区洞察

其他会员也浏览了