Sincronizzazione di più famiglie del database dell'utente con msimportauto.bat

In alcune situazioni, l'importazione corretta dei pacchetti di aggiornamento del database utente potrebbe dipendere dalle informazioni contenute negli altri pacchetti del database utente. Se il repository di schemi viene associato a più famiglie del database utente, l'importazione potrebbe avere esito negativo se i pacchetti non sono riprodotti nell'ordine in cui sono stati creati.

Lo script msimportauto.bat, incluso con questa versione di Rational ClearQuest, esegue la scansione della directory di importazione per i pacchetti di aggiornamento e quindi tenta di importare i pacchetti su ogni famiglia. Se i pacchetti sono stati importati correttamente, i pacchetti importati sono eliminati dalla directory e lo script tenta di importare il pacchetto successivo. Lo script interrompe l'esecuzione quando tutti i pacchetti sono riprodotti e la directory è vuota. Se una serie di tentativi di importazione non risulta in alcun pacchetto eliminato dalla directory, lo script arresta l'esecuzione e l'importazione ha esito negativo.

Le seguenti sezioni descrivono quando utilizzare lo strumento e fornire le istruzioni e gli esempi di sintassi.

Esempio

Un particolare gruppo, con i siti di Boston e Denver dispone di due database utente, User1 e User2. L'amministratore di Boston genera un pacchetto di sincronizzazione per User1 (Packet1) e quindi genera uno per User2 (Packet2). Mentre i pacchetti sono creati, un amministratore modifica le informazioni sull'account utente; causa l'inclusione del contenuto oplog del repository di schemi in entrambi i pacchetti del database dell'utente.

Quindi, l'amministratore di Boston crea un'altra coppia dei pacchetti di sincronizzazione del database utente per User1 (Packet3) e User2 (Packet4). Un amministratore modifica le informazioni sull'account utente mentre i pacchetti sono creati e il contenuto del file oplog del repository di schemi è incluso in entrambi i pacchetti del database utente.

Tutti i quattro pacchetti sono inviati al sito di Denver. Sul sito di Denver, l'amministratore esegue syncreplica -import e specifica la famiglia del database User1. Packet1 e Packet3 sono intesi per la famiglia User1. L'importazione di Packet1 è corretta e riproduce i file oplog in User1 e il repository di schemi. Tuttavia, l'importazione di Packet3 ha esito negativo, poiché dipende dai file oplog del database del repository di schemi contenuti in Packet2, che non sono stati ancora riprodotti sulla replica Denver.

Soluzione

Per evitare questa situazione, i pacchetti creati sul sito di esportazione devono essere riprodotti nella stessa sequenza sui siti di importazione. Utilizzare lo script msimportauto.bat.


Feedback