spox

Questo piccolo tutorial che scrivo serve per spiegare la procedura da seguire quando il nostro server SAP, entra in uno stato di log full.

Informazioni generali.

Tale tutorial è valido per chi amministra SAP su un sistema Operativo GNU/Linux e database MaxDB.

Sintomo

Quando l’area dei log è piena ( non c’è più spazio nei cosidetti log volumes) l’applicazione viene sospesa, e l’utente si trova in una situazione in cui non ci sono progressi e non riesce dunque ad effettuare alcuna operazione sul sistema, a cominciare dal logon. Ciò è dovuto al fatto che in tali situazioni di FULL LOG, tutti i tasks del database vengono sospesi finchè le vecchie “entry log” vengono sovrascritte.

Analisi

Mi sono reso conto del problema, cercando di collegarmi al mio sistema IDES tramite la mia java gui. Dopo aver selezionato il sistema SAP a cui collegarmi, è rimasta la popup “connecting” bloccata sul desktop (vedi figura sottostante).

Per identificare il problema ed accertarsi che siamo effettivamente di fronte ad un “LOG Full” , procediamo con le seguenti verifiche:

In prima istanza, come utente <sid>adm digitiamo nel terminale

host:sidadm> dbmcli -d SID -u control,password db_state -v

OK State ONLINE

Log Full      = Yes

Database Full = No

Per ulteriori analisi, come utente <sid>adm (nel mio caso UEDADM), in un terminale dare il comando:

x_cons SID sh ac 1

Il risultato di questo comando, mostrato dal sistema dovrebbe essere qualcosa simile a questo:

SERVERDB: UED

ID   UKT UNIX   TASK       APPL Current         Timeout Region     Wait

tid   type        pid state          priority cnt try    item
 T182   8     -1 User       5434 LOG FULL (246)        0 0               22449(s)
 T192   8     -1 User       6113 LOG FULL (246) !      0 0               22449(s)

Come è facile notare il nostro sistema è in blocco, dato che i log sono pieni e quindi non si riesce più ad effettuare alcuna operazione sul sistema stesso, finchè essi non verranno ripuliti.

Successivamente in un secondo terminale, diamo il comando sempre come utente

<sid>adm: dpmon

Ci verrà chiesto di inserire un opzione scegliamo “m”, e successivamente “p”, come illustrato nello screenshot in basso.

Una volta che abbiamo scelto di visualizzare la tabella di amministrazione dei work process (con p) avremo ancora più chiara la situazione.

Soluzione generale.

Quando abbiamo l’area log piena, occorre creare un backup degli stessi. Quando avviamo questa operazione, le vecchie entries dei log possono essere sovrascritte sul volume log. Tutti i task che erano stati sospesi ripartono, quando il primo segmento del log viene scritto sul dispositivo di backup

E’ possibile utilizzare per il log backup la DBMGUI (Database Manager GUI) oppure DBMCLI (client a linea di comando) utilizzando una sistassi del genere:

dbmcli -d <database_name> -u <dbm_user>,<password> backup_start <medium> LOG

<medium> indica il dispositivo di backup che è stato definito precedentemente attraverso il comando

medium_put.

N.B. Aggiungere un log volume non risolverà la situazione di log full.

Soluzione adottata.

La soluzione da me adottata è alquanto atipica, dato che la quantità a disposizione sul server non è sufficiente per immagazzinare i log del database MaxDB. Per uscire dallo stato di log full è stato dunque effettuato un “dummy backup” buttando via tutto, invece che salvarlo su un media esterno.
- Anzitutto è stata creata una pipe.

mknod /tmp/pipe p
chmod 777 /tmp/pipe

- E’ stato creato un dispositivo pipe backup

dbmcli -U c medium_put "PIPE" "/tmp/pipe" PIPE DATA 0 0 NO NO "" NONE

- ed ho avviato il backup, dando da terminale come utente sidadm il comando:

dbmcli -U c backup_start PIPE data

- contemporanemente, in una seconda finestra del terminale

dd if=/tmp/pipe of=/dev/zero

Tutto il processo avrà una durata abbastanza lunga, che dipenderà dalla mole dei dati immagazzinati.

Quando avremo completato questo step (backup dei dati del DB),dovremmo trovarci difronte a dei risultati del genere per i due comandi lanciati in precedenza:

dbmcli -U c -uUTL -c backup_start PIPE data

OK

Returncode              0

Date                    20070830

Time                    00102004

Server                  dolphin

Database                UED

Kernel Version          Kernel    7.6.00   Build 018-123-119-055

Pages Transferred       20989656

Pages Left              0

Volumes                 1

Medianame               PIPE

Location                /tmp/pipe

Errortext

Label                   DAT_000000004

Is Consistent           true

First LOG Page          887508

Last LOG Page

DB Stamp 1 Date         20070830

DB Stamp 1 Time         00101955

DB Stamp 2 Date

DB Stamp 2 Time

Page Count              20989575

Devices Used            1

Database ID             dolphin:UED_20070830_102004

Max Used Data Page      0

e

[root@dolphin bin]# dd if=/tmp/pipe of=/dev/zero

335834624+0 records in

335834624+0 records out

Procediamo dunque al backup dei log.

Creiamoci una nuova pipe su disco ed eseguiamo i seguenti comandi:

 dbmcli -d UED -u control,******
dbmcli on UED>db_execute SET LOG AUTO OVERWRITE OFF
OK

---
dbmcli on UED>db_connect
OK

---
dbmcli on UED>db_connect
OK

---

dbmcli on UED>backup_start PIPE

fonte: https://www.sdn.sap.com/irj/sdn/wiki?path=/display/MaxDB/Log%2bArea%2bFull

http://dev.mysql.com/doc/maxdb/en/default.htm