Prodotto | Tipo di comando |
---|---|
MultiSite | comando secondario multiutil |
Piattaforma |
---|
UNIX |
Windows |
–exp/ort[
–cl/an nome-gruppo ] [ –site nome-sito ] –fam/ily nome-famiglia
–u/ser nome utente [ –p/assword] password
[–max/size dimensione ] [–c/omments commenti ]
[–size dimensione-area-id ] [ –thres/hold soglia-area-id ]
{
{–sh/ip | –fsh/ip} -wor/kdir nomep-dir-temp
[–sc/lass classe-memorizzazione ]
[ –pex/pire data-ora ]
[–not/ify indirizzo-e-mail ]
| –out nomep-file-pacchetto } nome host:nome-sito ...
–imp/ort
{ –site nome-sito–repo/sitory info-db [ –vendor
tipo-fornitore ] parametri-db
}
{ [ –data/base db-info [ –vendor vendor-type ] db-params
[ –c/omments commenti ] { nomep-file-pacchetto|percorso-dir-pacchetto }...
–imp/ort {
[–cl/an nome-gruppo ] [ -site nome-sito ] –u/ser nome utente
[–p/assword ] password { –data/base info-db
[ –vendor tipo-fornitore ] parametri-db
[ –c/omments commenti ] { nomep-file-pacchetto|percorso-dir-pacchetto }...
L'esecuzione del comando mkreplica –export può richiedere del tempo. Il database e il repository di schemi sono bloccati durante l'esportazione. Verificare che tutti gli utenti non siano collegati prima di eseguire mkreplica –export.
La creazione di una nuova replica è un processo costituito da tre fasi:
In ciascun nuovo sito. l'amministratore deve creare dei database fornitore vuoti per i dati di replica. Se questa è la prima replica nel nuovo sito, sono necessari almeno due database fornitore vuoti, uno per la replica del repository di schemi e uno per la replica di database utente.
Quando un database viene replicato per la prima volta, l'oplog (operation log), vale a dire il log delle operazioni, del database viene abilitata. Tutte le operazioni da replicare sono registrate nell'oplog. Il log di tutte le operazioni continua fino a quando tutte le repliche sono eliminate, lasciando solo la serie di database originale. La creazione di repliche aggiuntive viene registrata nelle voci oplog. Le repliche esistenti vengono a conoscenza della nuova replica mediante il meccanismo di sincronizzazione standard.
MultiSite controlla in che modo molti numeri di ID record vengono assegnati ad ogni replica. Questa assegnazione viene eseguita utilizzando le aree ID (gruppi di ID).
Per impostazione predefinita, ad ogni replica viene fornita un'area ID di 4096 ID al momento della creazione. Quando una replica raggiunge la soglia di 1024 ID rimasti da utilizzare, le viene assegnata un'altra area ID di 4096 ID per garantire che tutti gli ID siano univoci. L'assegnazione dell'area ID è gestita internamente dal repository di schemi funzionante durante la sincronizzazione.
In base al livello di attività di una famiglia di repliche, può essere utile aumentare la dimensione dell'area ID assegnata ad una replica. Ad esempio, con le impostazioni predefinite, se si tenta di inoltrare un numero elevato di problemi, i primi 4096 sono inoltrati correttamente, ma gli inoltri successivi non riescono.
Per controllare quanti ID sono assegnati ad una replica, è possibile utilizzare l'opzione –size unitamente all'opzione –threshold quando si crea una replica con il comando mkreplica –export. È possibile modificare tali impostazioni con il comando chreplica.
Ogni richiamo di mkreplica –export crea un singolo pacchetto logico di creazione della replica. (Questo vale anche se si creano alcune nuove repliche con un comando mkreplica.) Ciascun pacchetto include una o più specifiche di repliche, ognuna delle quali indica il nome della nuova replica e il server di sincronizzazione associato alla nuova replica.
Il database utente e il repository di schemi sono bloccati durante la fase di esportazione.
L'opzione –maxsize divide il singolo pacchetto logico in più pacchetti fisici per motivi di compatibilità con le limitazioni del mezzo di trasferimento.
Se l'importazione di una replica viene interrotta o non riesce per qualunque motivo (un'interruzione dell'alimentazione, ad esempio), è necessario eliminare i database fornitore, creare nuovi database fornitore per l'operazione di importazione non riuscita ed eseguire di nuovo mkreplica –import.
È possibile importare correttamente il repository di schemi, ma non la replica del database utente. In questo caso, è necessario eliminare e ri-creare il database fornitore inteso per la replica del database utente.
I pacchetti di creazione della replica non vengono eliminati dopo l'importazione. dopo l'importazione di un pacchetto di creazione della replica con mkreplica –import, è necessario eliminare il pacchetto.
Se un pacchetto non può essere consegnato, esso viene rinviato mediante la funzione di memorizzazione e inoltro all'amministratore nel sito della replica di origine. Viene inviato un messaggio di posta all'amministratore di memorizzazione e inoltro. Questo si verifica dopo vari tentativi di consegna del pacchetto non riusciti quando il tempo assegnato è scaduto; ciò si verifica anche quando l'host di destinazione è sconosciuto o il file di dati non esiste. Le impostazioni di configurazione di memorizzazione ed inoltro specificano il periodo di scadenza, l'indirizzo e-mail dell'amministratore e il programma di notifica.
Blocchi: questo comando non riesce se il database è bloccato (ad esempio, durante un processo di aggiornamento) o mentre viene eseguita un'altra operazione di Rational ClearQuest MultiSite.
Altro: non è possibile replicare un database per un host dove è in esecuzione una versione diversa di MultiSite. È possibile eseguire mkreplica –export in qualsiasi sito; tuttavia è necessario eseguirlo sempre nel sito del repository di schemi funzionante per evitare la creazione di più siti con lo stesso nome.
Sito: il sito corrente. Se esiste più di un sito in questo host, –site è obbligatorio.
Famiglia: nessun valore predefinito; è necessario specificare una famiglia.
Famiglia di repository di schemi: non applicabile. Quando si esegue mkreplica, il repository di schemi associato della famiglia di database utente specificata viene incluso nel pacchetto di creazione della replica.
Valore predefinito: nessuno.
Il comando mkreplica non riesce se tenta di creare un pacchetto maggiore della dimensione supportata dal sistema.
–fship (force ship) richiama il comando shipping_server per inviare il pacchetto di creazione della replica. –ship inserisce il pacchetto in un vano di memoria. Per inviare il pacchetto, richiamare shipping_server.
La partizione del disco in cui è ubicato il vano di memoria (nell'host di invio e nell'host di ricezione) deve disporre di una quantità di spazio disponibile uguale o superiore della dimensione del pacchetto di creazione della replica.
Valore predefinito: mkreplica inserisce il pacchetto nell'ubicazione del vano di memoria specificato per la classe cq_default.
I pacchetti di creazione della replica non sono consegnati automaticamente; utilizzare un metodo appropriato per distribuirli. È possibile creare un pacchetto utilizzando –out e distribuirlo successivamente mediante la funzione di di memorizzazione e inoltro.
L'argomento data-ora può disporre di uno dei seguenti formati:
Specificare l'ora nel formato 24 ore, relativa al fuso orario locale. Se si omette l'ora, il valore predefinito è 00:00:00. se si omette la data, il valore predefinito è today. Se si omette il secolo, l'anno o una data specifica, viene utilizzata quella più recente. Specificare UTC se si desidera utilizzare l'ora da risolvere simultaneamente senza considerare il fuso orario. Utilizzare l'operatore più (+) o meno (-) per specificare la variazione positiva o negativa per l'ora UTC. Se si specifica UTC senza le variazioni dei minuti e delle ore, l'impostazione predefinita è GMT (Greenwich Mean Time). (Le date precedenti al 1° Gennaio 1970 UTC (Universal Coordinated Time) non sono valide.)
Se si verifica un errore su un host Windows che non ha la notifica e-mail abilitata, viene visualizzato un messaggio nel Visualizzatore di eventi Windows. Il messaggio include il valore indirizzo-e-mail specificato con questa opzione e una nota che richiede a questo utente di essere informato sullo stato dell'operazione.
Il nome host può essere l'indirizzo IP dell'host, il nome del computer, ad esempio minuteman. Può essere necessario inserire in nome dominio IP, ad esempio minuteman.purpledoc.com.
In Linux e UNIX, utilizzare il comando uname –n per visualizzare il nome del computer. In Windows, il nome del computer è accessibile dall'icona Sistema nel Pannello di controllo. In Windows 2000, fare clic sulla scheda Identificazione di rete. In Windows NT Server 2003, dare clic sulla scheda Nome computer.
Quando si importa una replica, è necessario specificare i parametri database del fornitore database per la replica del repository di schemi e il database fornitore per la replica database utente. È necessario creare questi database prima di importare un pacchetto di repliche.
Se si specifica anche uno o più argomenti percorso-dir-pacchetto, mkreplica ricerca i pacchetti aggiuntivi in queste directory.
Sito: il sito corrente. Se esiste più di un sito in questo host, –site è obbligatorio.
Specifica info-db e parametri-db per DB2, Oracle e Microsoft SQL Server
Ogni fornitore del database dispone di un numero di porta predefinito:
Fornitore | Porta predefinita |
---|---|
DB2 | 50000 |
Oracle | 1521 |
Microsoft SQL Server | 1433 |
Se il database utilizza una porta diversa, è necessario specificarla utilizzando il parametro connect-options. Ad esempio, se si dispone di un database Oracle sulla porta 1526, immettere il seguente comando:
multiutil mkreplica -imp -site SITEA -repo CQDEV -server cqsvr3 -vendor ORACLE -dbo admin_1 admin_1 -con PORT=1526 -data CQDEV -server cqsvr3 -vendor ORACLE -dbo admin_2 admin_2 -con PORT=1526 C:\TEMP\admin\mk_SITEA.xml
Importante: Per ulteriori informazioni sui valori supportati per i database del fornitore, consultare la sezione "Proprietà del database del fornitore" nella sezione Gestione di Rational ClearQuest della guida.
Se si specifica anche uno o più argomenti percorso-dir-pacchetto, mkreplica ricerca i pacchetti aggiuntivi in queste directory.
Valore predefinito: nessuno.
multiutil mkreplica -export -clan telecomm -site boston_hub -family DEV
-u susan -p passwd -out c:\cqms\boston_hub.xml goldengate:sanfran_hub
Multiutil: Packet file `c:\cqms\boston_hub.xml' generated
multiutil mkreplica -export -clan telecomm -site boston_hub -family LAB
-user susan -p passwd -out c:\cqms\lab.xml goldengate:sanfran_hub
Multiutil: Packet file `c:\cqms\lab.xml' generated
multiutil mkreplica -export -clan testing -site tokyo -family TEST
-user masako -p passwd -fship -workdir c:\cqms\working -sclass
cq_default taronga:sydney
Multiutil: Packet file
`c:\cqms\working\mk_TOKYO_29-January-02_09-47-27.xml' generated
multiutil: Shipping order
"C:\temp\cqms\ms_ship\outgoing\sh_o_mk_TOKYO_29-January-02_09-47-27.xml"
generated.
multiutil: Attempting to forward/deliver generated packets...
multiutil: -- Forwarded/delivered packet
C:\temp\cqms\ms_ship\outgoing\mk_TOKYO_29-January-02_09-4
multiutil mkreplia -export -clan telecomm -site boston_hub -family DEV
-user susan -password passwd -c "make a new replica for sanfran_hub"
-ship -workdir c:\temp\working -sclass cq_default
-pexpire 22-November-2003
goldengate:sanfran_hub
multiutil mkreplica -import -site sanfran_hub
-repository sanfran_schemarepo
-vendor SQL_SERVER -server sb_server -dbologin jcole passwd
-database sanfran_userdb -vendor SQL_SERVER
-dbologin jcole passwd
multiutil mkreplica -import -clan testing -site sydney -user bfife
-p passwd -database syd_userdb -vendor SQL_SERVER
-dbologin bfife passwd