Esplorare la disponibilità elevata di Oracle per SAP in Azure

  • 4 minuti

Windows e Oracle Linux sono gli unici sistemi operativi supportati da Oracle e Azure per i carichi di lavoro SAP. Le distribuzioni Linux SLES e RHEL, seppure ampiamente diffuse, non sono supportate per la distribuzione di componenti Oracle in Azure. I componenti Oracle includono il client Oracle Database, usato dalle applicazioni SAP per connettersi al sistema DBMS di Oracle.

Le eccezioni, in base alla nota SAP #2039619, sono componenti SAP che non usano il client Oracle Database. Tali componenti SAP sono l'accodamento autonomo di SAP, il server dei messaggi, i servizi di replica dell'accodamento, WebDispatcher e gateway SAP.

Anche se si eseguono le istanze del sistema DBMS di Oracle e delle applicazioni SAP in Oracle Linux, è possibile eseguire SAP Central Services in SLES o RHEL e proteggerlo con un cluster basato su Pacemaker. Pacemaker come framework a disponibilità elevata non è supportato in Oracle Linux (nota SAP #3074643).

Oracle Data Guard

Oracle Data Guard è supportato a scopo di disponibilità elevata. Per ottenere il failover automatico in Data Guard, è necessario usare FSFA (Fast-Start Failover). L'osservatore (FSFA) attiva il failover. Se non si usa FSFA, è possibile usare solo una configurazione di failover manuale.

Grazie a Data Guard è possibile gestire una copia identica di un database in hardware fisico separato. L'ideale è che tale hardware sia geograficamente lontano dal database primario. Data Guard non pone limiti alla distanza, anche se la distanza influisce sulle modalità di protezione. L'aumento della distanza aggiunge latenza tra i siti e pertanto alcune opzioni (come la replica sincrona) non saranno più funzionanti.

Data Guard offre alcuni vantaggi rispetto alla replica a livello di risorsa di archiviazione:

  • Poiché la replica è dipendente dal database, viene replicato solo il traffico pertinente.
  • Alcuni carichi di lavoro possono generare un input/output elevato sugli spazi tabella temporanei, che non sono necessari in modalità standby e quindi non vengono replicati.
  • La convalida dei blocchi replicati viene eseguita nel database in modalità standby, quindi i danni fisici del database primario non vengono replicati nel database in modalità standby.
  • Previene i danni logici all'interno dei blocchi e i danni da scritture perse. Elimina anche il rischio di errori commessi dagli amministratori della risorsa di archiviazione dalla replica nel database in modalità standby. La fase di rollforward può essere ritardata per un periodo predeterminato, in modo che gli errori degli utenti non vengano immediatamente replicati nel database in modalità standby.