Подготовката на фазата на адаптиране е първата фаза в цикъла на онлайн корекция в R12.2. Adop изпълнява много действия във фазата. Ето последователността от дейности
1. Проверява дали да извърши почистване, което ще е необходимо, ако потребителят не успее да извика почистване след фазата на прекъсване на предишен цикъл на онлайн корекция .
2.Потвърждава системната конфигурация, за да се гарантира, че системата е готова да започне онлайн цикъл на корекция.
3.Проверява дали базата данни е подготвена за онлайн корекция :
a) Проверява дали потребителят на базата данни е с разрешено издание. Ако не, adop незабавно излиза с грешка.
b) Проверява дали услугата за корекция е създадена. adop изисква да съществува специална услуга за база данни с цел свързване към изданието на корекцията. Тази услуга се създава автоматично, но продължаващото й съществуване се потвърждава при всяка подготовка.
в) Проверява дали тригерът за влизане съществува и е активиран. Ако тригерът за влизане липсва или услугата за корекция не е създадена, adop автоматично ще се опита да отстрани проблема, за да може да продължи. Ако не може да го направи, ще излезе със съобщение за грешка.
d) Проверява целостта на речника с данни на базата данни. Ако се открие някаква повреда, adop изходи с errorease 12.2.
д) Проверява дали E-Business Suite Technology Codelevel Checker (ETCC) е стартирана, за да провери дали всички необходими корекции са приложени към базата данни.
4.Проверява системната конфигурация на всеки възел от ниво приложение. Редица критични настройки са валидирани, за да се гарантира, че всеки възел на ниво приложение е правилно регистриран, конфигуриран и готов за корекция.
Проверява файловата система с помощта на TXK скрипта $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Този скрипт проверява за пространството на файловата система, връзките към базата данни, пароли за приложения/система/Weblogic, валидиране на контекстни файлове и т.н.
И също така генерира отчет, показващ информация за най-важните пространства за таблици. Този отчет е създаден в $APPL_TOP/admin/$TWO_TASK/out.
5.Проверява съществуването на „Онлайн корекцията в ход“ (ADZDPATCH) паралелна програма. Тази програма предотвратява стартирането на определени предварително дефинирани едновременни програми и като такава трябва да бъде активна, докато е в ход цикъл на корекция (тоест, докато съществува издание на корекция на базата данни).
Потокът на процеса е
a. Ако програмата ADZDPATCH все още не е поискана да се изпълнява, заявка се подава. Ако тя не съществува, се съобщава за грешка по-долу
ГРЕШКА на ред 1:
ORA-20008:Не е дефиниран Concurrent Manager, който може да изпълнява едновременна програма
ADZDPATCH
b.Определя се състоянието на ADZDPATCH. Ако е в изчакване, може да изчаква несъвместима програма да приключи. След като несъвместимостта е ясна, нейният статус ще се промени на работещ и ще позволи да продължи подготвителната фаза. Съобщение за този ефект се показва на потребителя.
c. Следващият етап зависи от това дали се изпълняват едновременните мениджъри:
i.Ако всички едновременни мениджъри са изключени, фазата на подготовка продължава, като ADZDPATCH влиза в състояние на чакащо (с най-висок приоритет), докато мениджърите не бъдат стартирани.
ii.Ако едновременните мениджъри са частично активирани, но има не е дефиниран мениджър, който може да изпълнява ADZDPATCH, тогава фазата на подготовка ще излезе с грешка.
iii.Ако едновременните мениджъри са активни и има дефиниран един, който може да изпълнява ADZDPATCH, обработката ще се завърти, докато ADZDPATCH промени състоянието от в очакване на бягане. След това фазата на подготовка продължава.
ADZDPATCH се отменя, когато фазата на прекъсване приключи.
Ако искате някоя персонализирана програма да не се изпълнява в цикъл на корекция, ще трябва да я направите несъвместима с тази програма
6.Извиква TXK скрипта $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl, за да синхронизира пачовете, които са приложени към изпълнението APPL_TOP, но не и към корекцията APPL_TOP. Скриптът зависи от хранилището на adop за корекции, които са били приложени при изпълнението APPL_TOP, но не и корекцията APPL_TOP.
Идентифицира пачовете, които са били приложени към изпълнението APPL_TOP и ги приложете към корекцията APPL_TOP. Следните стъпки се изпълняват автоматично:
a.Кърпите, които трябва да бъдат приложени към корекцията APPL_TOP, се идентифицират от базата данни.
b.Обединените пачове се прилагат от помощната програма adop.
Помощната програма adop идентифицира делта пачовете, които трябва да бъдат приложени, и ги прилага безшумно към текущата корекция APPL_TOP. Тъй като тази процедура изисква само прилагане на делта пачове, тя изисква по-малко време
При някои обстоятелства методът на синхронизация в делта стил (инкрементално) може да се провали при прилагане на серия от корекции към изданието на корекцията. Това може да се случи, ако предишният цикъл на корекция включва корекции, които не са успели да се приложат правилно, и е последван от последващи корекции, които коригират проблема.
Параметърът skipsyncerror ви позволява да укажете, че очаквате всички грешки при синхронизиране в подготвителната фаза да бъдат коригирани автоматично в синхронизацията, която се извършва с последващи корекции.
Ако стойността на параметъра е подадена като „да“, първата корекция, която трябва да се синхронизира, ще бъде извършена със зададен флаг „autoskip“.
Важно:Ваша отговорност е да проверите регистрационните файлове и да коригирате всички грешки в последващата фаза на прилагане или за да се потвърди, че синхронизирането с последващи пачове е разрешило проблема.
Пример за използване на този параметър би бил както следва.
a. Изпълнявате adop phase=prepare.
b. Фазата се проваля с грешка при опит за синхронизиране на файловите системи за изпълнение и корекция. Това означава, че опитът за синхронизиране на корекция е неуспешен, но е известно, че следваща корекция ще коригира проблема.
c. Проверявате регистрационните файлове и заключавате, че грешките при синхронизирането ще бъдат коригирани автоматично в синхронизацията, която отнема място с последващи пачове.
г. Изпълнявате командата adop phase=prepare skipsyncerror=yes, за да рестартирате подготвителната фаза. Този път прилагането на корекцията, което не е успяло при предишната подготовка, ще бъде опитано отново с зададен флаг „autoskip“.
Синхронизиране на персонализациите
Методът по подразбиране в делта стил (инкрементален) за синхронизиране на файловата система обработва официалните корекции, но няма да синхронизира ръчно приложени настройки. Примери за действия за корекция, които не са синхронизирани по подразбиране, включват:
Компилиране на потребителски дефинирани JSP
Копиране на някои библиотеки на трети страни
Копиране и компилиране на потребителски дефинирани едновременни програми
Копиране и генериране на дефинирани от потребителя формуляри
За да включите персонализирани действия за корекция в синхронизирането на файловата система по подразбиране, трябва да включите необходимите команди в драйвера за персонализирано синхронизиране, $APPL_TOP_NE/ad/custom/adop_sync.drv . Ще добавите вашите персонализации към следния раздел на файла:
#Начало на персонализиране
…
#Край на персонализиране
Всички действия, дефинирани в този файл, ще бъдат извършени от adop автоматично по време на фазата на подготовка. Имайте предвид, че има две категории персонализирани команди в adop_sync.drv:тези, които се изпълняват само един път, и тези, които се изпълняват при всяка синхронизация на файловата система (по време на фазата на подготовка за adop).
Важно:adop_sync. drv файл в момента не се нулира към своя шаблонен файл в нито един момент. Следователно, след превключване (и преди следващата фаза на подготовка), трябва да прегледате съдържанието на adop_sync.drv и да се уверите, че изискванията за вашите персонализирани команди продължават да бъдат изпълнени.
7.Проверява базата данни за наличието на корекция издание и създава такова, ако не го намери.
a)В базата данни се създава издание на корекция.
b)Всички кодови обекти в изданието на корекция започват като указатели към кодови обекти в изданието за изпълнение. Кодовите обекти в изданието на корекцията започват като олекотени „заглушки обекти“, които сочат към действителните дефиниции на обекти, които са наследени от по-ранни издания. Stub обектите заемат минимално пространство, така че изданието на корекцията на базата данни първоначално е много малко по размер.
c) Тъй като корекциите се прилагат към изданието на корекцията, кодовите обекти се актуализират (създават се нова дефиниция) в това издание.
8. Извиква отново скрипта $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl, за да потвърди, че връзката към базата данни към изданието на корекцията работи.
Сродни статии
Adop обяснено в R12.2
R12.2 Резюме на цикъла на онлайн корекция
