Przygotowanie do fazy przyjęcia jest pierwszą fazą cyklu poprawek online w wersji R12.2. Zastosuj, wykonaj wiele czynności w fazie.Oto sekwencja czynności
1.Sprawdza, czy wykonać czyszczenie, które będzie potrzebne, jeśli użytkownik nie wywoła czyszczenia po fazie przełączenia poprzedniego cyklu instalowania poprawek online .
2. Weryfikuje konfigurację systemu, aby upewnić się, że system jest gotowy do rozpoczęcia cyklu aktualizacji online.
3.Sprawdza, czy baza danych jest przygotowana do instalowania poprawek online :
a)Sprawdza, czy użytkownik bazy danych ma włączoną edycję. Jeśli nie, adop natychmiast kończy działanie z błędem.
b) Sprawdza, czy usługa poprawek została utworzona. adop wymaga istnienia specjalnej usługi bazy danych w celu połączenia z edycją poprawki. Ta usługa jest tworzona automatycznie, ale jej dalsze istnienie jest sprawdzane przy każdym przygotowaniu.
c) Sprawdza, czy wyzwalacz logowania istnieje i jest włączony. Jeśli brakuje wyzwalacza logowania lub usługa poprawek nie została utworzona, adop automatycznie spróbuje naprawić problem, aby można było kontynuować. Jeśli nie może tego zrobić, zakończy działanie z komunikatem o błędzie.
d)Sprawdza integralność słownika danych bazy danych. Jeśli zostanie znalezione jakiekolwiek uszkodzenie, adop kończy działanie z błędem 12.2.
e) Sprawdza, czy uruchomiono narzędzie E-Business Suite Technology Codelevel Checker (ETCC), aby sprawdzić, czy wszystkie wymagane poprawki zostały zastosowane do bazy danych.
4.Sprawdza konfigurację systemu na każdym węźle warstwy aplikacji. Szereg krytycznych ustawień jest sprawdzanych, aby zapewnić, że każdy węzeł warstwy aplikacji jest prawidłowo zarejestrowany, skonfigurowany i gotowy do zainstalowania poprawek.
Sprawdza system plików za pomocą skryptu TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Ten skrypt sprawdza miejsce w systemie plików, połączenia z bazą danych, hasła do aplikacji/systemu/Weblogic, sprawdzanie poprawności plików kontekstowych i tak dalej.
A także generuje raport pokazujący informacje o najważniejszych obszarach tabel. Ten raport jest tworzony w $APPL_TOP/admin/$TWO_TASK/out.
5.Sprawdza istnienie „Aktualizacji poprawek online” (ADZDPATCH) program współbieżny. Ten program zapobiega uruchamianiu pewnych predefiniowanych, współbieżnych programów i jako taki musi być aktywny, gdy trwa cykl aktualizacji (to znaczy, gdy istnieje edycja poprawki bazy danych).
Przebieg procesu to
a.Jeżeli program ADZDPATCH nie został jeszcze poproszony o uruchomienie, żądanie jest przesyłane.Jeśli nie istnieje, zgłaszany jest poniższy błąd
BŁĄD w wierszu 1:
ORA-20008:Nie zdefiniowano menedżera współbieżnego, który może uruchamiać program współbieżny
ADZDPPATCH
b. Ustalono status ADZDPATCH. Jeśli jest w toku, może czekać na zakończenie działania niezgodnego programu. Gdy niezgodność zostanie usunięta, jej status zmieni się na uruchomiony, co umożliwi kontynuację fazy przygotowania. Odpowiedni komunikat jest wyświetlany użytkownikowi.
c.Następny etap zależy od tego, czy są uruchomieni współbieżni menedżerowie:
i. Jeśli wszyscy współbieżni menedżerowie nie działają, faza przygotowania jest kontynuowana, a ADZDPATCH wchodzi w stan oczekiwania (o najwyższym priorytecie) do momentu uruchomienia menedżerów.
ii. Jeśli współbieżni menedżerowie częściowo działają, ale nie nie ma zdefiniowanego menedżera, który może uruchomić ADZDPATCH, faza przygotowania zakończy się z błędem.
iii. Jeśli współbieżni menedżerowie działają, a zdefiniowano jednego, który może uruchomić ADZDPATCH, przetwarzanie będzie wykonywane w pętli, dopóki ADZDPATCH nie zmieni statusu z oczekujące na uruchomienie . Faza przygotowania jest następnie kontynuowana.
ADZDPATCH jest anulowany po zakończeniu fazy przełączania.
Jeśli chcesz, aby jakiś niestandardowy program nie działał w cyklu patchowania, będziesz musiał uczynić go niekompatybilnym z tym programem
6. Wywołuje skrypt TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl w celu synchronizacji łatek, które zostały zastosowane do uruchomienia APPL_TOP, ale nie do poprawki APPL_TOP. Skrypt zależy od repozytorium adop dla łat, które zostały zastosowane przy uruchomieniu APPL_TOP, ale nie łaty APPL_TOP.
Zidentyfikuj poprawki, które zostały zastosowane do uruchomienia APPL_TOP i zastosuj je do poprawki APPL_TOP. Następujące kroki są wykonywane automatycznie:
a. Łatki, które należy zastosować do łaty APPL_TOP, są identyfikowane z bazy danych.
b.Połączone łaty są nakładane przez narzędzie adop.
Narzędzie adop identyfikuje łaty delta, które należy zastosować, i stosuje je po cichu do bieżącej łaty APPL_TOP. Ponieważ ta procedura wymaga jedynie zastosowania poprawek delta, zajmuje mniej czasu
W pewnych okolicznościach metoda synchronizacji w stylu delta (przyrostowa) może zawieść podczas stosowania serii poprawek do edycji poprawki. Może się to zdarzyć, jeśli poprzedni cykl poprawek zawierał poprawki, które nie zostały poprawnie zastosowane, a po nich następowały kolejne poprawki, które naprawiły problem.
Parametr skipsyncerror umożliwia określenie, że wszelkie błędy synchronizacji w fazie przygotowania zostaną naprawione automatycznie w synchronizacji, która ma miejsce z kolejnymi poprawkami.
Jeśli wartość parametru zostanie przekazana jako 'tak', pierwsza poprawka do zsynchronizowania zostanie wykonana z ustawioną flagą 'autoskip'.
Ważne:Twoim obowiązkiem jest sprawdzenie plików dziennika i poprawienie wszelkich błędów w w kolejnej fazie stosowania lub w celu potwierdzenia, że synchronizacja z kolejnymi poprawkami rozwiązała problem.
Przykład użycia tego parametru jest następujący.
a.Uruchamiasz adop phase=prepare.
b.Faza kończy się niepowodzeniem i błędem podczas próby synchronizacji systemu plików run i patch. Oznacza to, że próba zsynchronizowania łaty kończy się niepowodzeniem, ale wiadomo, że kolejna łata rozwiąże problem.
c.Sprawdzasz pliki dziennika i dochodzisz do wniosku, że błędy synchronizacji zostaną automatycznie naprawione w trakcie synchronizacji miejsce z kolejnymi łatami.
d.Uruchamiasz polecenie adop phase=przygotuj skipsyncerror=yes, aby zrestartować fazę przygotowania. Tym razem aplikacja poprawki, która nie powiodła się w poprzednim przygotowaniu, zostanie ponowiona z ustawioną flagą „autoskip”.
Synchronizacja dostosowań
Domyślna (przyrostowa) metoda synchronizacji systemu plików w stylu delta obsługuje oficjalne poprawki, ale nie synchronizuje żadnych ręcznie zastosowanych dostosowań. Przykłady akcji łatania, które nie są domyślnie synchronizowane, obejmują:
Kompilowanie plików JSP zdefiniowanych przez użytkownika
Kopiowanie bibliotek innych firm
Kopiowanie i kompilowanie jednoczesnych programów zdefiniowanych przez użytkownika
Kopiowanie i generowanie formularzy zdefiniowanych przez użytkownika
Aby uwzględnić niestandardowe działania poprawek w domyślnej synchronizacji systemu plików, musisz uwzględnić wymagane polecenia w niestandardowym sterowniku synchronizacji, $APPL_TOP_NE/ad/custom/adop_sync.drv . Dodasz swoje dostosowania do następującej sekcji pliku:
#Rozpocznij dostosowywanie
…
#Zakończ dostosowywanie
Wszystkie czynności zdefiniowane w tym pliku zostaną wykonane automatycznie przez adop podczas fazy przygotowania. Należy pamiętać, że w adop_sync.drv istnieją dwie kategorie poleceń niestandardowych:te, które są uruchamiane tylko raz i te, które są uruchamiane podczas każdej synchronizacji systemu plików (podczas fazy przygotowania do przyjęcia).
Ważne:Adop_sync. plik drv nie jest obecnie resetowany do pliku szablonu w żadnym momencie. W związku z tym po przełączeniu (i przed kolejną fazą przygotowania) należy przejrzeć zawartość pliku adop_sync.drv i upewnić się, że wymagania dla poleceń niestandardowych są nadal spełniane.
7.Sprawdza bazę danych pod kątem istnienia poprawki edycję i tworzy ją, jeśli jej nie znajdzie.
a)W bazie danych tworzona jest edycja poprawki.
b)Wszystkie obiekty kodu w edycji poprawki zaczynają się jako wskaźniki do obiektów kodu w edycji uruchomionej. Obiekty kodu w edycji poprawki zaczynają się jako lekkie „obiekty skrótów”, które wskazują na rzeczywiste definicje obiektów, które są dziedziczone z wcześniejszych edycji. Obiekty pośredniczące zajmują minimalną ilość miejsca, więc edycja poprawki bazy danych ma początkowo bardzo mały rozmiar.
c) Gdy poprawki są stosowane do edycji poprawki, obiekty kodu są aktualizowane (tworzą nową definicję) w tym wydaniu.
8. Ponownie wywołuje skrypt $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl, aby potwierdzić, że działa połączenie bazy danych z edycją poprawki.
Powiązane artykuły
Zastosowanie wyjaśnione w R12.2
Podsumowanie systemu aktualizacji R12.2 online
