HowTo upgrade a Sap instance

Premessa

Questa documentazione descrive quali sono gli step generali che si devono obbligatoriamente seguire per eseguire un upgrade con successo di una release di SAP

• Passi Preliminari

Qui vengono descritti i passi preliminari con un ordine specifico da seguire prima di arrivare alla esecuzione delle fasi di prepare dell’upgrade

a) identificazione di release di partenza e di arrivo

b) reperire il manuale di upgrade alla release di arrivo

c) check delle note in esso contenute e dei relativi rimandi ad altre note

d) particolare attenzione al livello di support package attuali, se sono particolarmente elevati nel sistema di arrivo si deve studiare un livello di patch da inserire durante l’upgrade per prevenire problemi di perdita di correzioni utili

e) Non consentire di modificare il livello di support package di produzione DOPO aver eseguito l’upgrade nel sistema di TEST al fine di non trovarsi in una situazione inaspettata

f) porre attenzione alla release del database richiesto per eseguire correttemente la fase di prepare

g) Documentare OPPORTUNAMENTE qualsiasi passo di preparazione per non trovarsi spiazzati nell’upgrade di produzione

• Passi di preparazione

In un landscape standard SVILUPPO-TEST-PRODUZIONE il modo corretto di procedere e’

1) refresh ambiente di produzione sull’ambiente di TEST. Pareggiamento profili d’istanza con i parametri presenti nella produzione per avere il piu’ possibile un ambiente speculare alla produzione. Tenere conto delle risorse del sistema di test per la parametrizzazione dei buffer SAP e parametrizzazione Oracle.

2) Adeguamento parametrizzazione Sistema Operativo secondo gli ultimi dettami SAP e soprattutto se il sistema operativo e’ supportato per la release di arrivo sia di SAP che di oracle

3) Accertarsi di avere tutte le librerie specifiche richieste dall’upgrade e di avere un release di java installata, funzionante ed il cui path e’ presente nel path dell’utente [sid]adm

4) Scarico delle support package richieste e relativo unpacking nella EPS/in del sistema in questione. Molte procedure di upgrade richiedono anche di inserire nella EPS/in sia la SPAM update del sistema di arrivo che quella di partenza. Per quest ultima e’ opportuno caricarla prima della partenza della prepare

5) Scaricare sempre l’ultima versione del tool di upgrade (R3up SAPup etc etc ) da porre nella /bin e di conseguenza anche le relative FIX . Devono essere ENTRAMBE all’ultima versione.

6) Scaricare i CD possibilmente in un'unica cartella e o filesystem denominando ogni singolo CD con una nomenclatura di facile interpretazione (eg KERNELCD , EXPORT1 , LANG1 etc etc )

7) Porre attenzione ad eventuali script ( in particolare per oracle) che possano accelerare alcune fasi di upgrade. Al termine dell’upgrade eseguire gli script di ripristino della situazione esistente

8) Predisporre sempre un backup offline del DB , dei file di environment di SIDADM (nel caso di sistemi windows fare backup anche del registry) , e del kernel PRIMA di partire con la PREPARE e prima anche del lancio dell’UPGRADE .

• Passi di esecuzione PREPARE

1) Creare una upgrade directory di almeno 7 GB . Posizionarsi nella upgrade directory e da li' lanciare il PREPARE . Dopo questo lancio dare l’exit , sostiture nella bin il nuovo tool di trasporto e rilanciare la procedura .

2) Far chiudere tutte le CR in stato modificabile sul sistema ed aprire il customizing da SCC4 . Lasciarlo aperto per tutto il periodo dell’upgrade

3) Eseguire backup della tabella dei WAGE TYPE (buste paga) come richiesto da molti manuali di upgrade

4) Essere in possesso delle password di DDIC sul client 000 e SYSTEM, fondamentali per le fasi di input iniziali. Da NON modificare durante nessuna fase dell’upgrade. Puo’ accadere che in alcune fasi dell’upgrade sia richiesto il logon con DDIC e compaia un prompt di modifica password. In tal caso re-imputare la stessa.

5) Eseguire TUTTE le fasi della PREPARE, comprese quelle opzionali, e porre particolare attenzione alle fase opzionali di salvataggio delle varianti. Si consiglia per queste fasi di SALVARE tutto il possibile . Per i sistemi BW questa fase e’ fondamentale visto che molte query BW vengono reintrodotte proprio con le fasi finali dell’upgrade.

6) Una delle fasi piu’ delicate e’ la BIND_PATCH. Nelle release piu’ recenti SAP molti plug-in sono gia’ inseriti nei CD standard di SAP e quindi a fronte della dicitura INST/UPG WITH STD CD il SAPup (o R3up) ha GIA’ trovato come procedere per questi plug-in e quindi dare semplicemente OK alla fase (senza flaggare nulla). Se dovesse comparire una dicitura del tipo UNDECIDED in tal caso bisogna scaricare il .SAR relativo da OSS e caricarlo nella EPS/in e procedere all’upgrade mediante SAINT. Non far cancellare il plug-in all’upgrade. Sono ASSOLUTAMENTE critici i PI e gli ST-PI che, se cancellati durante l’upgrade, rendono inconsistente l’upgrade stesso. Leggere le note relative, utilizzare come chiave “upgrade with PI “. A margine delle note principali in genere c’è sempre un rimando.

7) Aggiornare sempre le statistiche del DB ponendo attenzione alla modalita particolare con cui il brconnect ad esempio deve essere lanciato per l’oracle 10

• Passi dell’upgrade .

1) Eseguire sempre backup OFFLINE dell’istanza e della UPGDIR prima del lancio dell’upgrade.

2) Non modificare alcun input delle fasi di prepare e mettere Db in NOARCHIVE MODE

3) A fronte di un errore non documentato esaminare il log della fase nella upgdir/log e/o tmp . Tentare un rilancio della fase.

4) In caso di errori particolari cercare la fase (nome tecnico, descrizione) su SAPOSS, SDN, Motori di ricerca.

5) Porre molta attenzione all’analisi del LONGPOST

• Passi post-upgrade

1) Eseguire backup offline al termine dell’upgrade

2) cancellare le tablespace della vecchia release

3) seguire tutti i passi richiesti dal manuale come post-action

4) ricordarsi di reimportare le entries della tabella dei wage types come richiesto dal manuale