Oracle
 sql >> Database >  >> RDS >> Oracle

Come utilizzare Distributed AD per ridurre il tempo di applicazione delle patch in Oracle EBS

1) L'AD distribuito offre una migliore scalabilità, prestazioni e utilizzo delle risorse consentendo l'avvio di lavoratori della stessa sessione AD su sistemi di livello intermedio aggiuntivi.

2) AD ha sempre utilizzato un sistema di lavori paralleli, in cui più lavoratori AD iniziano e vengono assegnati lavori. Le informazioni per il Jobs System sono archiviate nel database Oracle e i lavoratori ricevono i loro incarichi monitorando determinate tabelle nel database.

3) L'AD distribuito consente ai lavoratori di essere avviati su macchine remote, dove possono utilizzare le risorse sulle macchine remote quando completano i lavori assegnati

Prerequisiti
1) APPL_TOP condivisa
2) AD.H

Lavorando
Su uno dei tuoi nodi APPL_TOP condivisi, avvia la sessione AutoPatch(adpatch) o AD Administration(adadmin) con le seguenti opzioni della riga di comando:

localworkers= workers=

Ad esempio per eseguire una sessione di AutoPatch con 3 lavoratori sul nodo locale e 5 lavoratori su un nodo remoto:

adpatch localworkers=3 workers=8

Su uno o più nodi APPL_TOP condivisi aggiuntivi, avvia una sessione di AD Controller con la seguente opzione della riga di comando:

adctrl distributed=y

Dopo aver fornito le informazioni di base, il controller AD richiederà l'avvio dei numeri di lavoro. Ad esempio, immettere "4 5 6 7 8" o "4-8" per avviare i lavoratori da 4 a 8. Se AD Controller viene avviato prima che AutoPatch o Amministrazione AD avvii il Jobs System, AD Controller chiederà se si desidera attendere. Scegliendo sì, AD Controller attenderà fino all'avvio del sistema Jobs, a quel punto avvierà i processi di lavoro appropriati. Se una sessione di AutoPatch è già stata avviata, AD Controller attenderà automaticamente.

Esempio di una sessione a due nodi con cinque lavoratori:

Node 1) adpatch localworkers=30 workers=20

Node 2) adctrl distributed=y and choose Enter the worker range 21-30

Per R12.2, le cose rimangono le stesse, dobbiamo solo usare adop al posto di adpatch

Esempio 1:distribuisci un totale di otto lavoratori su un sistema a due nodi
1. Per iniziare, inserisci un comando che eseguirà una sessione di adozione con tre worker sul
nodo primario e cinque worker sui nodi secondari:

$ adop phase=apply input_file=myinput.txt

Il file myinput.txt dovrà includere le righe:
workers=8
localworkers=3
2. Ora avvia una sessione di AD Controller su ciascuno dei nodi secondari che eseguiranno
workers, usando l'argomento distribuito=y.

$ adctrl distributed=y
  1. Per avviare i lavoratori da 4 a 8 su un nodo secondario, inserisci "4-8" in risposta al
    prompt di AD Controller:
    Inserisci l'intervallo di lavoro:4-8

Esempio 2:distribuire un totale di dodici lavoratori su un sistema a tre nodi
1. Per iniziare, inserisci un comando che eseguirà una sessione di adozione con quattro worker sul
nodo primario e otto worker sui nodi secondari:

$ adop phase=apply input_file=myinput.txt workers=12 localworkers=4

Il file myinput.txt dovrà includere le righe:
workers=12
localworkers=4
2. Ora avvia una sessione di AD Controller sul secondo nodo, specificando che i worker 5-8
dovrebbero essere eseguiti lì:

$ adctrl distributed=y

Inserisci l'intervallo di lavoro:5-8
3. Infine, avvia AD Controller sul terzo nodo, specificando che gli ultimi quattro worker
(9-12) devono essere eseguiti lì:

$ adctrl distributed=y

Inserisci l'intervallo di lavoro:9-12

Articoli correlati

Patch di Oracle:Panoramica completa di Adpatch

31 Riga di comando adop (AD online patching) utile per R12.2

Adop (utilità di patching online per annunci) spiegata R12.2

40 Attacca la domanda che ogni DBA dovrebbe conoscere