Thank you for the response.
Hi Steven,I know this question very well! The IT guy, configuring your database server asks, why you really need a second card.Well, in times when we had physical machines, not only a machine could fail, but also a NIC. If you just have one and the NIC of the Primary fails, your Secondary has to become primary (but the former primary will not change state and hence you could get a so called split-brain situation as soon as the old primary machine becomes online again).If they have a second NIC to communicate over, such situations are much simpler to avoid.Also, as mentioned in your referenced best practices paper on page 7/8, one of the important things in a high performant HADR system is to reduce the latency of commit processing. E.g. if you run HADR in SYNC, an application commiting it's changes has to wait until the primary has written its transaction logs, the primary sends over the logbuffer to the standby, the standby has to write them to disk (and apply in parallel) before the standby acknowledges the logbuffer to the primary, which in turn can now return from the commit call back to the application.If you have a separate network for this communication, commit latency will be smaller than if you have to compete with all the data packages sent to the clients. Neglecting any backups and other traffic right now.Now today a lot of machines are virtualized and the VM host might have a twin channel NIC with bonding to the network to prevent outages and increase transfer. So assigning a second virtual NIC to your VM would send all the traffic over the same adapter. It neither helps you for preventing split brain, nor helping in bandwidth.
So for a simple data base in an HADR cluster this might be sufficient. But if you have e.g. a high performance SAP database for thousands of users, you might want to have this extra x% in performance option.It depends. Your mileage will vary.