Caso d'uso · Oracle
Monitoraggio Oracle per SAP, con un'utenza che legge soltanto
SUPtime interroga Oracle via SQL con un'utenza dedicata di sola lettura e mette query lente, tabelle, backup RMAN e tablespace accanto alle sonde Basis dello stesso sistema. Dalla 10.2 in su, quindi anche i sistemi ECC e R/3 che nessuno ha ancora migrato.
Cosa legge
Le viste di sistema, una per una
Solo viste dinamiche V$ e viste del catalogo DBA_: mai tabelle applicative, mai Diagnostics Pack, niente AWR o Statspack. Senza le credenziali del database, la scheda lo dichiara invece di mostrare numeri.
| Sorgente | Cosa mostra |
|---|---|
| V$INSTANCE · V$DATABASE | Versione, nome dell'istanza e del database, uptime dallo STARTUP_TIME |
| V$OSSTAT | CPU e memoria dell'host |
| V$SESSION · V$SYSSTAT | Connessioni attive e inattive, hit ratio della buffer cache |
| V$SQLAREA | Le query più lente e il tempo medio di risposta |
| DBA_SEGMENTS · DBA_TABLES | Le tabelle più grandi e quelle che scegli di sorvegliare, con le righe dall'ultima raccolta statistiche |
| V$BACKUP_SET · V$BACKUP_PIECE | Esito ed età degli ultimi backup RMAN |
| SDBAH | Esito ed età dei backup BR*Tools: un SAP che fa brbackup senza RMAN non risulta «senza backup» |
| DBA_DATA_FILES · DBA_FREE_SPACE · DBA_TEMP_FILES | Occupazione dei tablespace, calcolata come allocato meno libero, e dimensione del database |
| DBA_OUTSTANDING_ALERTS | Gli alert che il server genera da solo, con motivo e azione suggerita da Oracle |
| V$ARCHIVE_DEST_STATUS · V$LOG · V$LOGFILE | Destinazioni dell'archiver in errore e redo log non archiviati, solo se il database è in ARCHIVELOG |
| V$SESSION (BLOCKING_SESSION) | Sessioni bloccate, da chi e da quanto |
| DBA_USERS · DBA_ROLE_PRIVS (utenza propria) | Se l'utenza di monitoraggio è ancora OPEN, quando scade, quali ruoli ha |
Ogni mattina
Le domande di un Basis su Oracle
Il backup di stanotte è andato?
Esito ed età dell'ultimo backup, letti sia da RMAN sia dallo storico BR*Tools: chi usa brbackup non risulta senza backup. Un backup vecchio si vede prima che serva.
I tablespace reggono?
Allocato meno libero, tablespace per tablespace. Un PSAPSR3 pieno ferma SAP: meglio saperlo con margine.
L'archiver sta scrivendo?
Se una destinazione è in errore o tutti i redo log aspettano di essere archiviati, il database si fermerà a breve. Ed è il primo problema Oracle che un Basis vede davvero.
Cosa rallenta il sistema?
Query più lente dalla shared pool, tabelle più grandi e sessioni bloccate.
Salute di Oracle
Non solo carico: la diagnostica che Oracle già calcola
Il server genera i suoi alert da solo, con motivo e azione suggerita. SUPtime li raccoglie invece di duplicarli, e ci aggiunge i tre segnali che su un sistema SAP contano di più.
Alert generati dal server
Warning e critici, con la spiegazione e l'azione suggerita da Oracle: non solo un contatore.
Archiver e redo log
Destinazione in errore o redo log tutti non archiviati. Su un database in NOARCHIVELOG il check non scatta: non c'è niente da archiviare, e un falso allarme insegna a ignorare quelli veri.
Sessioni bloccate
Chi è bloccato, da chi, da quanti secondi.
La stessa utenza di monitoraggio
Se è ancora OPEN, quando scade la password, quali ruoli ha: un blocco dell'utenza si vede in scheda, non nei log.
Versioni
Dalla 10.2 alla 23ai, con lo stesso script
Le viste usate sono quelle disponibili dalla 8i in poi, apposta: niente che esista solo dalle versioni recenti, così lo script dell'utenza vale ovunque senza modifiche.
Oracle 12.1 e successive
Il driver Python si collega da solo, senza librerie Oracle sul server di SUPtime.
Oracle 10.2 e 11g
Servono le librerie client di Oracle sul server di SUPtime, una tantum. Il connettore passa da solo alla modalità che serve, senza configurare nulla per sistema.
SID o service name
Si sceglie nel form del sistema. Le installazioni SAP più vecchie espongono solo il SID, e va bene così.
Accesso
Un'utenza di sola lettura, non SAPSR3
Mai il proprietario dello schema
SAPSR3 può scrivere su ogni tabella. SUPtime legge e basta, quindi usa un'utenza dedicata con CREATE SESSION e i SELECT che servono.
Niente DBA, niente SELECT_CATALOG_ROLE
Quel ruolo coprirebbe tutto con un comando, ma copre anche molto altro. Si preferisce l'elenco esplicito, vista per vista: la documentazione lo riporta con il perché di ogni riga.
Non si blocca da sola
Dopo credenziali rifiutate il connettore smette di ritentare per 15 minuti: un profilo Oracle blocca l'utenza dopo pochi tentativi, e un monitoraggio non deve chiudersi la porta da solo.
Stesso sistema, due canali
Oracle e ABAP nella stessa vista
Sonde Basis via RFC
Dump, job, blocchi e Security Audit Log dello stack ABAP che gira su quel database.
Anche senza RFC
Un sistema configurato con il solo database mostra le schede del database e la disponibilità via sapcontrol; le schede che vivono solo di RFC restano disattivate, senza mostrare zeri.
Regole su qualunque monitor
Il monitor ORACLE porta i problemi già valutati: «almeno un problema aperto» scatta al primo e rientra da solo quando non ce n'è più.
Limiti dichiarati
Cosa non copre
Sapere cosa un monitoraggio non vede conta quanto sapere cosa vede.
- Crescita del database nel tempo: senza AWR non esiste una cronologia interna da cui calcolarla, e un numero stimato al posto di uno vero non si mette in scheda.
- Data Guard, RAC e failover: nessuna gestione, e nessuno stato letto oltre a quello dell'archiver.
- Diagnostics e Tuning Pack: non richiesti e non usati. Le query lente vengono da V$SQLAREA, non da AWR.
- Funzionalità che richiederebbero più dei SELECT elencati: per scelta di sicurezza, non vengono implementate.
- Previsioni: SUPtime mostra i valori letti, non stima quelli futuri.
Vuoi vederlo sul tuo Oracle?
Ti mostriamo le schede su un sistema reale e lo script dell'utenza di sola lettura, grant per grant.