Franchement quel vilain cet AWR… Non ? Me faire ça à moi, No data exists for this section of the report, n’ai je donc tant administré de bases que pour cette infamie ? Un peu de respect que diable !!!
Pourtant j’ai vérifié statistics_level est bien positionné à ‘TYPICAL’ et il y a des clichés dans dba_hist_snapshot
SQL> select snap_id 2 , to_char(end_interval_time,'YY/MM/DD HH24:MI:SS') EIT 3 from dba_hist_snapshot 4 where end_interval_time > trunc(sysdate) 5 order by 1 6 /
SNAP_ID EIT
---------- ---------------------------------------------------
5534 13/07/26 00:00:52
5535 13/07/26 01:00:54
5536 13/07/26 02:00:57
5537 13/07/26 03:00:59
5538 13/07/26 04:00:02
5539 13/07/26 05:00:04
5540 13/07/26 06:00:07
5541 13/07/26 07:00:09
5542 13/07/26 08:00:12
5543 13/07/26 09:00:14
5544 13/07/26 10:00:17
5545 13/07/26 11:00:19
5546 13/07/26 12:00:22
5547 13/07/26 13:00:25
Oui mais le hic c’est que dans les tables qui vont bien c’est le vide sidéral …. Sidérant1 non ?
SQL> select snap_id 2 , count(*) cpt 3 from dba_hist_sqlstat 4 where SNAP_ID between 5534 and 5547 5 group by SNAP_ID 6* order by 1 SQL> / no rows selected
Aïe
La solution :
SQL> alter system set control_management_pack_access = 'DIAGNOSTIC+TUNING' scope = both;
Oui je passe le paramètre à sa valeur par défaut, les données de diagnostique et de les outils de réglage (oui, tuning ça signifie “réglage”) sont accessibles à tous. Et s’ils sont accédés par mégarde, gare à la surprise sur la facture. C’est certainement ce dernier point qui a motivé un vilain garnement à modifier le paramétrage lors de la création de la base, cependant le vilain en question me prive de l’historique des métriques et je vais encore bougonner tout le week-end du coup.
… Le souci c’est que ça ne fonctionne pas systématiquement !!!
En effet les collectes reprennent mais pas toutes, notamment pas de statistiques système, pas d’historique d’ASH, je dois bien avouer que tout cela me rend un poil chafouin. J’en m’en suis donc ouvert au support Oracle et ils ont réussi, c’est une tradition chez tous les se(r)vices “support”, ils ont donc réussi à finir de m’énerver.
En effet la solution préconisée dans mon cas est le redémarrage de la base, qui fonctionne il faut bien l’avouer, mais ne réponds pas aux exigences de disponibilité de bases de production. Ça m’énerve d’autant plus que le paramètre control_management_pack_access est annoncé comme modifiable au niveau système et donc ne nécessitant pas de redémarrage de base pour être complètement effectif. Il y a donc là bug bogue.
Reste à le faire admettre à mon service support préféré et là ça risque d’être sportif.
1. Oui, je sais, elle est nulle. [retour]