Adop fase forberedelse er den første fase i online patching cyklus i R12.2. Adop udfører en masse handlingspunkter i fasen. Her er rækkefølgen af aktiviteter
1.Tjekker, om der skal udføres en oprydning, som vil være nødvendig, hvis brugeren ikke kunne påberåbe sig oprydning efter cutover-fasen af en tidligere online patch-cyklus .
2.Validerer systemkonfigurationen for at sikre, at systemet er klar til at starte en online patch-cyklus.
3.Tjekker for at se, om databasen er forberedt til online-patching :
a)Tjekker, om databasebrugeren er edition-aktiveret. Hvis ikke, afsluttes Adop med det samme med en fejl.
b) Kontrollerer, om patch-tjenesten er blevet oprettet. adop kræver, at der findes en speciel databasetjeneste med det formål at oprette forbindelse til patch-udgaven. Denne tjeneste oprettes automatisk, men dens fortsatte eksistens valideres ved hver forberedelse.
c) Kontrollerer, om logon-trigger findes og er aktiveret. Hvis logon-triggeren mangler, eller patch-tjenesten ikke er blevet oprettet, vil adop automatisk forsøge at løse problemet, så det kan fortsætte. Hvis den ikke kan gøre det, afsluttes den med en fejlmeddelelse.
d)Tjekker integriteten af databasens dataordbog. Hvis der findes en korruption, skal du adop exits med en fejlfrihed 12.2.
e) Kontrollerer, at E-Business Suite Technology Codelevel Checker (ETCC) er blevet kørt for at verificere, at alle påkrævede patches er blevet anvendt på databasen.
4.Tjekker systemkonfigurationen på hver applikationsniveauknude. En række kritiske indstillinger valideres for at sikre, at hver node på applikationsniveau er korrekt registreret, konfigureret og klar til patching.
Kontrollerer filsystemet ved hjælp af TXK-scriptet $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Dette script tjekker for filsystemplads, databaseforbindelser, Apps/System/Weblogic-adgangskoder, Contextfile Validation og så videre
Og det producerer også en rapport, der viser information om de vigtigste tablespaces, der genereres. Denne rapport er oprettet i $APPL_TOP/admin/$TWO_TASK/out.
5.Kontrollerer, om der findes "Online Patching in Progress" (ADZDPATCH) samtidig program. Dette program forhindrer visse foruddefinerede samtidige programmer i at blive startet, og skal som sådan være aktive, mens en patch-cyklus er i gang (det vil sige mens en database-patch-udgave eksisterer).
Processflowet er
a.Hvis ADZDPATCH-programmet endnu ikke er blevet bedt om at køre, sendes en anmodning. Hvis den ikke eksisterer, rapporteres nedenstående fejl
FEJL på linje 1:
ORA-20008:Der er ikke defineret nogen Concurrent Manager, der kan køre samtidig program
ADZDPATCH
b. Status for ADZDPATCH bestemmes. Hvis det afventer, venter det muligvis på, at et inkompatibelt program er færdigt. Når inkompatibiliteten er klar, ændres dens status til kørende, og det vil tillade forberedelsesfasen at fortsætte. En meddelelse herom vises til brugeren.
c. Det næste trin afhænger af, om de samtidige administratorer kører:
i.Hvis de samtidige ledere er helt nede, fortsætter forberedelsesfasen, hvor ADZDPATCH går ind i en status af afventende (med højeste prioritet), indtil lederne er startet.
ii.Hvis de samtidige ledere er delvist oppe, men der er der ikke defineret en manager, der kan køre ADZDPATCH, så afsluttes forberedelsesfasen med en fejl.
iii.Hvis de samtidige managere er oppe, og der er defineret en, der kan køre ADZDPATCH, vil behandlingen gå i løkke, indtil ADZDPATCH ændrer status fra afventer at køre. Forberedelsesfasen fortsætter derefter.
ADZDPATCH annulleres, når cutover-fasen er afsluttet.
Hvis du ønsker, at et brugerdefineret program ikke skal køre i patch-cyklus, bliver du nødt til at gøre det inkompatibelt med dette program
6. Starter TXK-scriptet $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl for at synkronisere de patches, som er blevet anvendt på kørslen APPL_TOP, men ikke patchen APPL_TOP. Scriptet afhænger af adop-lageret for patches, der er blevet anvendt på kørslen APPL_TOP, men ikke patchen APPL_TOP.
it Identificer de programrettelser, der blev anvendt på kørslen APPL_TOP, og anvend dem på patchen APPL_TOP. Følgende trin udføres automatisk:
a. De patches, der skal anvendes på patchen APPL_TOP, identificeres fra databasen.
b.De flettede patches påføres af adop-værktøjet.
Adop-værktøjet identificerer delta-patches, der skal anvendes, og anvender dem lydløst til den aktuelle patch APPL_TOP. Da denne procedure kun kræver påføring af delta-patches, kræver den mindre tid
I nogle tilfælde kan delta-stil (trinvis) synkroniseringsmetode mislykkes, når der anvendes en række patches til patch-udgaven. Dette kan ske, hvis den forrige programrettelsescyklus indeholdt patches, der ikke kunne anvendes korrekt, og blev efterfulgt af efterfølgende patches, der korrigerede problemet.
Skipsyncerror-parameteren giver dig mulighed for at angive, at du forventer, at eventuelle synkroniseringsfejl i forberedelsesfasen bliver rettet automatisk i den synkronisering, der finder sted med efterfølgende patches.
Hvis værdien af parameteren sendes som "ja", vil den første patch, der skal synkroniseres, blive udført med "autoskip"-flaget.
Vigtigt:Det er dit ansvar at kontrollere logfilerne og rette eventuelle fejl i den efterfølgende anvendelsesfase eller for at bekræfte, at synkronisering med efterfølgende patches løste problemet.
Et eksempel på brug af denne parameter ville være som følger.
a.Du kører adop phase=prepare.
b.Fasen mislykkes med en fejl, når du forsøger at synkronisere kørsels- og patch-filsystemerne. Det vil sige, at forsøget på at synkronisere en patch mislykkes, men det er kendt, at en efterfølgende patch vil rette problemet.
c.Du undersøger logfilerne og konkluderer, at synkroniseringsfejlene vil blive rettet automatisk i den synkronisering, der tager placere med efterfølgende patches.
d.Du kører kommandoen adop phase=prepare skipsyncerror=yes for at genstarte forberedelsesfasen. Denne gang vil anvendelsen af patchen, der mislykkedes i den forrige forberedelse, blive prøvet igen med "autoskip"-flaget sat.
Synkronisering af tilpasninger
Standardmetoden i delta-stil (inkrementel) til filsystemsynkronisering håndterer officielle patches, men vil ikke synkronisere nogen manuelt anvendt tilpasning. Eksempler på patchhandlinger, der ikke er synkroniseret som standard, omfatter:
Kompilering af brugerdefinerede JSP'er
Kopierer nogle tredjepartsbiblioteker
Kopiering og kompilering af brugerdefinerede samtidige programmer
Kopiering og generering af brugerdefinerede formularer
For at inkludere brugerdefinerede patch-handlinger i standardfilsystemsynkroniseringen skal du inkludere de nødvendige kommandoer i Custom Synchronization Driver, $APPL_TOP_NE/ad/custom/adop_sync.drv stærk> . Du tilføjer dine tilpasninger til følgende sektion af filen:
#Begynd tilpasning
…
#Afslut tilpasning
Alle handlinger, der er defineret i denne fil, udføres automatisk af adop under forberedelsesfasen. Vær opmærksom på, at der er to kategorier af brugerdefinerede kommandoer i adop_sync.drv:dem, der kun køres én gang, og dem, der køres ved hver filsystemsynkronisering (under adop-forberedelsesfasen).
Vigtigt:Adop_sync. drv-filen er i øjeblikket ikke nulstillet til sin skabelonfil på noget tidspunkt. Derfor bør du efter cutover (og før næste forberedelsesfase) gennemgå indholdet af adop_sync.drv og sikre dig, at kravene til dine brugerdefinerede kommandoer fortsat er opfyldt.
7.Tjekker databasen for eksistensen af en patch udgave, og opretter en, hvis den ikke finder en.
a)Der oprettes en patch-udgave i databasen.
b)Alle kodeobjekter i patch-udgaven begynder som pointere til kodeobjekter i den kørende udgave. Kodeobjekter i patch-udgaven begynder som lette "stub-objekter", der peger på de faktiske objektdefinitioner, som er nedarvet fra tidligere udgaver. Stub-objekter bruger minimalt med plads, så databasepatch-udgaven er i begyndelsen meget lille i størrelse.
c) Efterhånden som patches anvendes på patch-udgaven, aktualiseres kodeobjekter (få en ny definition oprettet) i den udgave.
8. Kalder $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl scriptet igen for at bekræfte, at databaseforbindelsen til patch-udgaven fungerer.
Relaterede artikler
Adop forklaret i R12.2
R12.2 Online patching-oversigt