De voorbereiding van de adoptiefase is de eerste fase in de online patchcyclus in R12.2. Adop voer veel actie-items uit in de fase. Hier is de volgorde van activiteiten
1. Controleert of er een opschoning moet worden uitgevoerd, wat nodig is als de gebruiker de opschoning niet heeft gestart na de overgangsfase van een eerdere online patchcyclus .
2. Valideert de systeemconfiguratie om ervoor te zorgen dat het systeem klaar is om een online patchcyclus te starten.
3.Controleert of de database is voorbereid voor online patching :
a)Controleert of de databasegebruiker editie-enabled is. Als dit niet het geval is, wordt adop onmiddellijk afgesloten met een fout.
b) Controleert of de patchservice is gemaakt. adop vereist dat er een speciale databaseservice bestaat om verbinding te maken met de patcheditie. Deze service wordt automatisch aangemaakt, maar het voortbestaan ervan wordt bij elke voorbereiding gevalideerd.
c) Controleert of de aanmeldingstrigger bestaat en is ingeschakeld. Als de aanmeldingstrigger ontbreekt of de patchservice niet is gemaakt, zal Adop automatisch proberen het probleem op te lossen zodat het verder kan gaan. Als het dit niet kan, wordt het afgesloten met een foutmelding.
d)Controleert de integriteit van de database datadictionary. Als er corruptie wordt gevonden, sluit Adop af met errorease 12.2.
e) Controleert of de E-Business Suite Technology Codelevel Checker (ETCC) is uitgevoerd om te controleren of alle vereiste patches op de database zijn toegepast.
4.Controleert de systeemconfiguratie op elk knooppunt van de applicatielaag. Een aantal kritieke instellingen wordt gevalideerd om ervoor te zorgen dat elk knooppunt op de applicatielaag correct is geregistreerd, geconfigureerd en klaar voor patching.
Controleert het bestandssysteem met behulp van het TXK-script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Dit script controleert de bestandssysteemruimte, databaseverbindingen, Apps/Systeem/Weblogic-wachtwoorden, Contextbestandsvalidatie enzovoort
En het produceert ook een rapport met informatie over de belangrijkste tabelruimten die wordt gegenereerd. Dit rapport is gemaakt in $APPL_TOP/admin/$TWO_TASK/out.
5.Controleert op het bestaan van de “Online Patching In Progress” (ADZDPATCH) gelijktijdig programma. Dit programma voorkomt dat bepaalde vooraf gedefinieerde gelijktijdige programma's worden gestart en moet als zodanig actief zijn terwijl een patchcyclus aan de gang is (dat wil zeggen, terwijl er een databasepatcheditie bestaat).
De processtroom is
a.Als het ADZDPATCH-programma nog niet is gevraagd om te worden uitgevoerd, wordt een verzoek ingediend.Als het niet bestaat, wordt hieronder een fout gerapporteerd
ERROR op regel 1:
ORA-2008:Er is geen Concurrent Manager gedefinieerd die een gelijktijdig programma kan draaien
ADZDPATCH
b.De status van ADZDPATCH wordt bepaald. Als het in behandeling is, wacht het mogelijk tot een incompatibel programma is voltooid. Nadat de incompatibiliteit duidelijk is, verandert de status in actief en kan de voorbereidingsfase doorgaan. Een bericht hierover wordt aan de gebruiker getoond.
c.De volgende fase hangt af van of de gelijktijdige managers actief zijn:
i.Als de gelijktijdige managers allemaal down zijn, gaat de voorbereidingsfase verder, waarbij ADZDPATCH de status in behandeling (met de hoogste prioriteit) krijgt totdat de managers zijn gestart.
ii.Als de gelijktijdige managers gedeeltelijk omhoog zijn, maar er is er geen manager gedefinieerd die ADZDPATCH kan uitvoeren, dan wordt de voorbereidingsfase afgesloten met een fout.
iii.Als de gelijktijdige beheerders actief zijn, en er is er één gedefinieerd die ADZDPATCH kan uitvoeren, wordt de verwerking herhaald totdat de status van ADZDPATCH verandert van in afwachting van hardlopen. De voorbereidingsfase gaat dan verder.
ADZDPATCH wordt geannuleerd wanneer de overgangsfase is voltooid.
Als u wilt dat een aangepast programma niet in de patchcyclus wordt uitgevoerd, moet u het incompatibel maken met dit programma
6. Roept het TXK-script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl op om de patches te synchroniseren die zijn toegepast op de run APPL_TOP, maar niet op de patch APPL_TOP. Het script is afhankelijk van de geadopteerde repository voor patches die zijn toegepast op de run APPL_TOP, maar niet van de patch APPL_TOP.
it Identificeer de patches die zijn toegepast op de run APPL_TOP en pas ze toe op de patch APPL_TOP. De volgende stappen worden automatisch uitgevoerd:
a.De patches die moeten worden toegepast op de patch APPL_TOP worden geïdentificeerd uit de database.
b.De samengevoegde patches worden toegepast door het hulpprogramma Adop.
Het hulpprogramma Adop identificeert de delta-patches die moeten worden toegepast, en past ze stil toe op de huidige patch APPL_TOP. Omdat deze procedure alleen de toepassing van delta-patches vereist, kost het minder tijd
In sommige omstandigheden kan de delta-stijl (incrementele) synchronisatiemethode mislukken bij het toepassen van een reeks patches op de patcheditie. Dit kan gebeuren als de vorige patchcyclus patches bevatte die niet correct konden worden toegepast en werd gevolgd door daaropvolgende patches die het probleem hebben verholpen.
Met de parameter skipsyncerror kunt u specificeren dat u verwacht dat eventuele synchronisatiefouten in de voorbereidingsfase automatisch worden verholpen in de synchronisatie die plaatsvindt met daaropvolgende patches.
Als de waarde van de parameter als 'ja' wordt doorgegeven, wordt de eerste patch die moet worden gesynchroniseerd uitgevoerd met de vlag 'autoskip'.
Belangrijk:het is uw verantwoordelijkheid om de logbestanden te controleren en eventuele fouten in de daaropvolgende toepassingsfase, of om te bevestigen dat synchronisatie met daaropvolgende patches het probleem heeft opgelost.
Een voorbeeld van het gebruik van deze parameter is als volgt.
a.U voert adop phase=prepare uit.
b.De fase mislukt met een fout bij het synchroniseren van de run- en patchbestandssystemen. Dat wil zeggen, de poging om een patch te synchroniseren mislukt, maar het is bekend dat een volgende patch het probleem zal oplossen.
c.U onderzoekt de logbestanden en concludeert dat de synchronisatiefouten automatisch worden verholpen in de synchronisatie die nodig is plaats met daaropvolgende patches.
d.U voert het commando adop phase=prepare skipsyncerror=yes uit om de voorbereidingsfase te herstarten. Deze keer wordt de toepassing van de patch die bij de vorige voorbereiding mislukte, opnieuw geprobeerd met de vlag 'autoskip'.
Aanpassingen synchroniseren
De standaard delta-stijl (incrementele) methode voor bestandssysteemsynchronisatie verwerkt officiële patches, maar synchroniseert geen handmatig aangebrachte aanpassingen. Voorbeelden van patchacties die niet standaard worden gesynchroniseerd zijn:
Door de gebruiker gedefinieerde JSP's samenstellen
Sommige bibliotheken van derden kopiëren
Door de gebruiker gedefinieerde gelijktijdige programma's kopiëren en compileren
Door de gebruiker gedefinieerde formulieren kopiëren en genereren
Als u aangepaste patchacties wilt opnemen in de standaardsynchronisatie van het bestandssysteem, moet u de vereiste opdrachten opnemen in het stuurprogramma voor aangepaste synchronisatie, $APPL_TOP_NE/ad/custom/adop_sync.drv . U voegt uw aanpassingen toe aan het volgende gedeelte van het bestand:
#Begin Customization
...
#End Customization
Alle acties die in dit bestand zijn gedefinieerd, worden tijdens de voorbereidingsfase automatisch door Adop uitgevoerd. Houd er rekening mee dat er twee categorieën van aangepaste commando's zijn in adop_sync.drv:degenen die eenmalig worden uitgevoerd en degenen die worden uitgevoerd bij elke synchronisatie van het bestandssysteem (tijdens de adoptievoorbereidingsfase).
Belangrijk:de adop_sync. drv-bestand is momenteel op geen enkel moment teruggezet naar het sjabloonbestand. Daarom moet u na de overgang (en vóór de volgende voorbereidingsfase) de inhoud van adop_sync.drv controleren en ervoor zorgen dat aan de vereisten voor uw aangepaste opdrachten blijft worden voldaan.
7.Controleert de database op het bestaan van een patch editie, en maakt er een aan als deze er geen vindt.
a) Er wordt een patcheditie gemaakt in de database.
b) Alle code-objecten in de patch-editie beginnen als verwijzingen naar code-objecten in de run-editie. Code-objecten in de patch-editie beginnen als lichtgewicht "stub-objecten" die verwijzen naar de werkelijke objectdefinities, die zijn overgenomen van eerdere edities. Stub-objecten nemen minimale ruimte in beslag, dus de database-patcheditie is aanvankelijk erg klein.
c) Als patches worden toegepast op de patch-editie, worden code-objecten geactualiseerd (er wordt een nieuwe definitie gemaakt) in die editie.
8. Roept het script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl opnieuw op om te bevestigen dat de databaseverbinding met de patcheditie werkt.
Gerelateerde artikelen
Adopteren uitgelegd in R12.2
R12.2 Online patching-systeemoverzicht