Embora a largura de banda da rede entre em grande escala, o fator número um absoluto a considerar é qual é a taxa de geração de logs de transação no principal?
Se o aplicativo e sua manutenção não gerarem nenhum log de transações, a largura de banda da rede será realmente irrelevante. Se ele gerar log, a largura de banda da rede deverá ser capaz de lidar com a quantidade de log gerada.
Para responder a sua pergunta real, sua configuração do h / w pode funcionar (problemas de rede à parte) se não houver uma grande carga de trabalho de OLTP no principal. Se houver, e você tiver núcleos de processador 4x4 gerando o log de transações, é provável que o seu servidor espelho não consiga acompanhar a repetição do log, não importa se a sua rede pode lidar com o tráfego de log. Na edição Standard, há um thread que processa o REDO do log no espelho - para que sua fila REDO fique bem grande sob carga pesada.
A fila REDO é a quantidade de log que foi endurecida no espelho, mas que ainda não foi reproduzida no banco de dados espelho - quanto maior, mais tempo será antes que o banco de dados espelhado atue como o principal no evento de um failover. Isso é especialmente problemático no Standard Edition, no qual você não tem recursos como refazer em paralelo e recuperação rápida (o banco de dados fica on-line após o REDO e antes do UNDO) estar disponível.
E, é claro, depois de um failover do principal para o espelho, não há como o espelho ser capaz de atender a mesma carga de trabalho do servidor principal - então você estará lá, mas possivelmente executando muito mais devagar.
Espero que isso ajude.
.gif){kind=link}