Příprava fáze přijetí je první fází cyklu online oprav v R12.2. Adop provádí ve fázi mnoho akcí. Zde je posloupnost činností
1. Zkontroluje, zda provést vyčištění, které bude potřeba, pokud se uživateli nepodařilo vyvolat vyčištění po fázi přerušení předchozího online záplatovacího cyklu .
2. Ověřuje konfiguraci systému, aby bylo zajištěno, že je systém připraven zahájit cyklus online oprav.
3.Zkontroluje, zda je databáze připravena pro online záplatování :
a)Zkontroluje, zda má uživatel databáze povolenou edici. Pokud ne, adop okamžitě skončí s chybou.
b) Zkontroluje, zda byla vytvořena opravná služba. adop vyžaduje, aby existovala speciální databázová služba pro účely připojení k opravné edici. Tato služba je vytvořena automaticky, ale její další existence je ověřena při každé přípravě.
c) Zkontroluje, zda existuje aktivační událost přihlášení a zda je povolena. Pokud spouštěč přihlášení chybí nebo nebyla vytvořena opravná služba, adop se automaticky pokusí problém vyřešit, aby mohl pokračovat. Pokud tak nemůže učinit, ukončí se s chybovou zprávou.
d) Kontroluje integritu databázového datového slovníku. Pokud je nalezeno jakékoli poškození, adop se ukončí s chybou 12.2.
e) Kontroluje, že byl spuštěn E-Business Suite Technology Codelevel Checker (ETCC), aby se ověřilo, že na databázi byly aplikovány všechny požadované záplaty.
4.Kontroluje konfiguraci systému na každém uzlu aplikační vrstvy. Ověřuje se řada důležitých nastavení, aby bylo zajištěno, že každý uzel aplikační vrstvy je správně zaregistrován, nakonfigurován a připraven k opravě.
Zkontroluje systém souborů pomocí skriptu TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Tento skript kontroluje prostor souborového systému, databázová připojení, hesla Apps/System/Weblogic, ověřování kontextových souborů a tak dále
A také vytváří zprávu zobrazující informace o nejdůležitějších tabulkových prostorech. Tento přehled je vytvořen v $APPL_TOP/admin/$TWO_TASK/out.
5. Zkontroluje existenci „Probíhá online oprava“ (ADZDPATCH) souběžný program. Tento program zabraňuje spuštění určitých předdefinovaných souběžných programů a jako takový musí být aktivní, když probíhá cyklus oprav (to znamená, když existuje edice oprav databáze).
Tok procesu je
a.Pokud program ADZDPATCH ještě nebyl požádán o spuštění, je odeslán požadavek. Pokud neexistuje, je hlášena níže uvedená chyba
CHYBA na řádku 1:
ORA-20008:Není definován žádný Concurrent Manager, který by mohl spouštět souběžný program
ADZDPATCH
b.Je stanoven stav ADZDPATCH. Pokud čeká na vyřízení, může čekat na dokončení nekompatibilního programu. Po vyjasnění nekompatibility se její stav změní na spuštěný a umožní pokračování přípravné fáze. Uživateli se zobrazí zpráva v tomto smyslu.
c.Další fáze závisí na tom, zda běží souběžní správci:
i.Pokud jsou všichni souběžní manažeři mimo provoz, přípravná fáze pokračuje, přičemž ADZDPATCH vstoupí do stavu nevyřízeno (s nejvyšší prioritou), dokud nejsou manažeři spuštěni.
ii.Pokud jsou souběžní manažeři částečně nahoře, ale není definován žádný správce, který by mohl spouštět ADZDPATCH, pak přípravná fáze skončí s chybou.
iii.Pokud jsou souběžní správci aktivní a je definován jeden, který může spouštět ADZDPATCH, zpracování se bude opakovat, dokud ADZDPATCH nezmění stav z čeká na spuštění . Poté pokračuje přípravná fáze.
ADZDPATCH se po dokončení fáze přerušení zruší.
Pokud chcete, aby se jakýkoli vlastní program nespouštěl v cyklu oprav, budete jej muset učinit nekompatibilním s tímto programem
6. Vyvolá TXK skript $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl k synchronizaci oprav, které byly aplikovány na běh APPL_TOP, ale ne na opravu APPL_TOP. Skript závisí na úložišti adop pro opravy, které byly aplikovány při běhu APPL_TOP, ale ne na opravě APPL_TOP.
it Identifikuje záplaty, které byly aplikovány na běh APPL_TOP, a aplikujte je na záplatu APPL_TOP. Následující kroky se provedou automaticky:
a.Záplaty, které je třeba aplikovat na záplatu APPL_TOP, jsou identifikovány z databáze.
b. Sloučené záplaty jsou aplikovány obslužným programem adop.
Obslužný program adop identifikuje delta záplaty, které se mají použít, a tiše je aplikuje na aktuální patch APPL_TOP. Protože tento postup vyžaduje pouze aplikaci delta záplat, vyžaduje méně času
Za určitých okolností může metoda synchronizace ve stylu delta (přírůstková) selhat při použití série oprav na edici oprav. To se může stát, pokud předchozí cyklus oprav zahrnoval opravy, které se nepodařilo správně aplikovat, a po kterých následovaly opravy, které problém opravily.
Parametr skipsyncerror vám umožňuje určit, že očekáváte, že všechny chyby synchronizace ve fázi přípravy budou automaticky opraveny při synchronizaci, která probíhá s následnými opravami.
Pokud je hodnota parametru předána jako 'yes', bude první oprava, která má být synchronizována, provedena s nastaveným příznakem 'autoskip'.
Důležité:Je vaší odpovědností zkontrolovat soubory protokolu a opravit případné chyby v následná fáze aplikace nebo potvrzení, že synchronizace s následujícími opravami problém vyřešila.
Příklad použití tohoto parametru by byl následující.
a.Spustíte adop phase=prepare.
b.Fáze selže s chybou při pokusu o synchronizaci běhu a opravy souborových systémů. To znamená, že pokus o synchronizaci opravy selže, ale je známo, že následná oprava problém napraví.
c. Prozkoumáte soubory protokolu a dojdete k závěru, že chyby synchronizace budou opraveny automaticky při synchronizaci, která trvá místo s následnými záplatami.
d. Spusťte příkaz adop phase=prepare skipsyncerror=yes pro restart fáze přípravy. Tentokrát bude aplikace opravy, která selhala v předchozí přípravě, zopakována s nastaveným příznakem „autoskip“.
Synchronizace přizpůsobení
Výchozí metoda synchronizace systému souborů ve stylu delta (přírůstková) zpracovává oficiální opravy, ale nebude synchronizovat žádné ručně aplikované úpravy. Příklady akcí oprav, které nejsou ve výchozím nastavení synchronizovány, zahrnují:
Kompilace uživatelsky definovaných JSP
Kopírování některých knihoven třetích stran
Kopírování a kompilace uživatelsky definovaných souběžných programů
Kopírování a generování uživatelsky definovaných formulářů
Chcete-li do výchozí synchronizace systému souborů zahrnout vlastní akce oprav, musíte zahrnout požadované příkazy do ovladače vlastní synchronizace $APPL_TOP_NE/ad/custom/adop_sync.drv . Svá přizpůsobení přidáte do následující části souboru:
#Begin Customization
…
#End Customization
Všechny akce definované v tomto souboru provede adop automaticky během přípravné fáze. Uvědomte si, že v adop_sync.drv jsou dvě kategorie vlastních příkazů:ty, které se spouštějí pouze jednou, a ty, které se spouštějí při každé synchronizaci systému souborů (během fáze přípravy adop).
Důležité:adop_sync. drv není aktuálně resetován na svůj soubor šablony v žádném okamžiku. V důsledku toho byste po přerušení (a před další fází přípravy) měli zkontrolovat obsah souboru adop_sync.drv a zajistit, aby byly nadále splněny požadavky na vaše vlastní příkazy.
7. Zkontroluje, zda v databázi neexistuje oprava edici a vytvoří ji, pokud ji nenajde.
a)V databázi je vytvořena edice opravy.
b)Všechny objekty kódu v edici opravy začínají jako ukazatele na objekty kódu v edici spuštění. Objekty kódu v edici patchů začínají jako lehké „pahýlové objekty“, které ukazují na skutečné definice objektů, které jsou zděděny z dřívějších edic. Objekty stub zabírají minimální místo, takže edice oprav databáze má zpočátku velmi malou velikost.
c) Jak jsou na edici opravy aplikovány opravy, aktualizují se v této edici objekty kódu (vytvoří se nová definice). P>
8. Znovu zavolá skript $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl, aby potvrdil, že připojení databáze k edici opravy funguje.
Související články
Adop Explained in R12.2
Shrnutí cyklu online oprav R12.2