Ottimizzare il sistema di origine - Opzioni avanzate

Completato

Queste indicazioni più avanzate possono essere utili per l'esportazione di origine dei sistemi VLDB:

Suddivisione della tabella di ID di riga Oracle

SAP ha rilasciato la nota SAP n. 1043380 che contiene uno script che converte la clausola WHERE in un file WHR in un valore di ID di riga. In alternativa, le versioni più recenti di SAPInst generano automaticamente i file WHR delle suddivisioni di ID di riga se SWPM è configurato per la migrazione da Oracle a Oracle R3load. I file STR e WHR generati da SWPM sono indipendenti dal sistema operativo e dal database (come tutti gli aspetti del processo di migrazione del sistema operativo e del database).

La nota OSS specifica che la suddivisione della tabella ROWID NON PUÒ essere usata se il database di destinazione non è un database Oracle. Tecnicamente, i file dump R3load sono indipendenti dal database e dal sistema operativo. C'è tuttavia una limitazione, ovvero il riavvio di un pacchetto durante l'importazione non è possibile in SQL Server. In questo scenario sarà necessario eliminare l'intera tabella e tutti i pacchetti per riavviare la tabella. È sempre consigliabile terminare le attività R3load per una tabella divisa specifica, usare il comando TRUNCATE per la tabella e riavviare l'intero processo di importazione in caso di errore di una tabella R3load divisa. Il motivo è che il processo di ripristino integrato in R3load comporta l'esecuzione di istruzioni DELETE riga per riga per rimuovere i record caricati dal processo R3load interrotto. Questa operazione è lenta e spesso causa situazioni di blocco nel database. L'esperienza ha dimostrato che è più veloce avviare l'importazione della tabella specifica dall'inizio, pertanto la limitazione indicata nella nota SAP n. 1043380 non è una vera limitazione.

L'ID di riga presenta uno svantaggio in quanto il calcolo delle divisioni deve essere eseguito durante il tempo di inattività. Vedere la nota SAP n. 1043380.

Creare più "cloni" del database di origine ed eseguire l'esportazione in parallelo

Un metodo per migliorare le prestazioni di esportazione consiste nell'eseguire l'esportazione da più copie dello stesso database. Se l'infrastruttura sottostante, inclusi server, rete e risorse di archiviazione, è scalabile, questo approccio tende a essere scalabile in modo lineare. L'esportazione da due copie dello stesso database sarà due volte più veloce e da quattro copie sarà quattro volte più veloce. Migration Monitor è configurato per l'esportazione in un numero selezionato di tabelle da ogni "clone" del database. Nel caso seguente, il carico di lavoro di esportazione viene distribuito approssimativamente per il 25% in ognuno dei 4 server di database.

• Server di database 1 e server di esportazione 1: dedicati alle prime quattro tabelle più grandi (a seconda del grado di asimmetria della distribuzione dei dati nel database di origine)
• Server di database 2 e server di esportazione 2: dedicati alle tabelle con suddivisioni
• Server di database 3 e server di esportazione 3: dedicati alle tabelle con suddivisioni
• Server di database 4 e server di esportazione 4: dedicati a tutte le tabelle rimanenti

Fare molta attenzione per assicurare che i database siano sincronizzati con precisione, altrimenti potrebbero verificarsi perdite di dati o incoerenze nei dati. Se i passaggi indicati di seguito vengono seguiti con precisione, l'integrità dei dati viene mantenuta.

Questa tecnica è semplice ed economica con hardware Intel standard, ma è anche possibile per i clienti che eseguono hardware UNIX proprietario. Le risorse hardware sostanziali sono gratuite nella parte centrale di un progetto di migrazione di sistema operativo e database quando i sistemi sandbox, di sviluppo, di controllo di qualità, di training e di ripristino di emergenza sono già stati spostati in Azure. Non è rigorosamente necessario che i server "clone" abbiano risorse hardware identiche. Con un livello adeguato di prestazioni di rete, CPU, RAM e disco, l'aggiunta di ogni clone migliora le prestazioni.

Se sono ancora necessarie prestazioni di esportazione ulteriori, aprire un incidente SAP in BC-DB-MSS per ulteriori passaggi per migliorare le prestazioni di esportazione (solo per consulenti avanzati).

I passaggi per implementare un'esportazione parallela multipla sono i seguenti:

1. Eseguire il backup del database primario e ripristinarlo in un numero "n" di server, dove n = numero di cloni. Per questo esempio, si supponga che n = 3 server che esemplino un totale di quattro server di database.
2. Ripristinare il backup in tre server.
3. Stabilire il log shipping dal server di database di origine primario ai tre server "clone" di destinazione.
4. Monitorare il log shipping per diversi giorni e assicurarsi che funzioni in modo affidabile.
5. All'inizio del tempo di inattività, arrestare tutti i server applicazioni SAP ad eccezione di PAS. Verificare che l'elaborazione batch venga arrestata e che tutto il traffico RFC venga arrestato.
6. Nella transazione SM02 immettere il testo "Checkpoint PAS Running". Verrà così aggiornata la tabella TEMSG.
7. Arrestare il server applicazioni primario. SAP è ora arrestato. Non possono essere eseguite attività di scrittura nel database di origine. Assicurarsi che nessuna applicazione non SAP sia connessa al database di origine (non devono mai essere presenti, ma verificare la presenza di sessioni non SAP a livello di database).
8. Eseguire questa query nel server di database primario: SELECT EMTEXT FROM [schema].TEMSG;
9. Eseguire l'istruzione del livello DBMS nativo: INSERT INTO [schema].TEMSG “CHECKPOINT R3LOAD EXPORT STOP dd:mm:yy hh:mm:ss” (la sintassi esatta dipende dal livello DBMS di origine. INSERT into EMTEXT)
10. Interrompere i backup del log delle transazioni automatici. Eseguire manualmente un backup del log delle transazioni finale nel server di database primario. Verificare che il backup del log venga copiato nei server clone.
11. Ripristinare il backup del log delle transazioni finale in tutti e tre i nodi.
12. Ripristinare il database nei tre nodi "clone".
13. Eseguire l'istruzione SELECT seguente in tutti e quattro i nodi: SELECT EMTEXT FROM [schema].TEMSG;
14. Acquisire i risultati sullo schermo dell'istruzione SELECT per ognuno dei quattro server di database (il database primario e i tre cloni). Assicurarsi di includere ogni nome host, che fungerà da prova che il database clone e il database primario sono identici e contengono gli stessi dati dello stesso momento specifico.
15. Avviare export_monitor.bat in ogni server di esportazione Intel R3load.
16. Avviare la copia del file dump nel processo di Azure (AzCopy o Robocopy).
17. Avviare import_monitor.bat nelle macchine virtuali di Azure R3load.

Il diagramma seguente mostra un log shipping dei server di database di produzione esistenti nei database "clone". Ogni server di database ha uno o più server Intel R3load.