Demandé par le support Oracle pour connaitre la version du Cluster Ready Service noeud par noeud, le passage des instructions crsctl query crs en masse peut être fastidieux. Voici donc une petite fonction bash pour obtenir les informations sous linux. Il faut bien sûr qu’elle soit lancée par l’utilisateur propriétaire de la grid-infrastructure et que la variable GI_HOME corresponde à son répertoire d’installation
(suite…)
Je ne sais pas s’il existe vraiement un niveau 0 de l’exploitation des SGBD oracle, mais le redimensionnement, à la hausse, des fichiers de tablespaces est du niveau le plus trivial qui soit. Cependant, à peine plus compliqué, il est parfois nécessaire de redimensionner les redo logs, ou plus précisément les “archived red log files”. C’est pourtant parfois nécessaire quand par exemple on constate un nombre de switch trop élevé. Il est recommandé d’en avoir 3 à 4 par heures et on les comptes soit en mode texte avec SQL*Plus soit de manière plus graphique avec l’outil qui vous semblera bon.
L’idée de maintenir un code de qualité pour à peu près tout est reste souvent un veux pieux. On verra ici comment utiliser Git et Visual Studio Code qui permettent de travailler proprement et rapidement. Cependant, leur mise en place bien qu’aisée n’est pas évidente. Ce petit guide est mon aide mémoire personnel pour les installer.
Télécharger Git pour Windows ou votre OS préféré. En fin de configuration, lancer le shell bash, puis passer les commandes suivantes afin de paramétrer les informations relatives à votre dépot :
Depuis quelques version d’Oracle, la gestion de la mémoire a été simplifiée, comprenez que le nombre de paramètres minimal liés à sa gestion a été considérablement réduit. En clair, il suffirait de positionner le volume global de mémoire à allouer à l’instance par le truchement du paramètre memory_target et par le biais de réallocations dynamiques oracle serait capable de se débrouiller. On constate bien vite que c’est faux notamment pour le tuning sga.
Comme d’habitue lors de ce genre de cas, si on laisse l’initiative à Oracle, au bout d’un moment la mémoire finit par fragmenter et malgré une taille globale suffisante on rencontre de vilaines erreurs ORA-4031. Et plus généralement ce mode d’allocation (via memory_target donc) n’est pas compatible avec l’utilisation de huge pages. Il est donc recommandé de tuner les différentes sous-sections de mémoire, la pga au travers de pga_aggregate_target et la sga au travers de sga_target. Ces deux paramètres seuls ne suffisent cependant encore pas et il faut positionner des valeurs pour les divers pools et caches de la SGA qui seront considérées comme des minimums.
La question qui se pose régulièrement lors du réglage des instances Oracle est comment est gérée la mémoire sous Linux et plus généralement, de combien de mémoire puis-je disposer pour mon instance ( mes instances ? ). En effet, la littérature est assez peu fournie sur la métrologie de la mémoire sous linux et on se retrouve souvent avec des données incompréhensibles. C’est notamment le cas de la commande free, qui peut très bien afficher un espace libre de 0, en permanence, sans que cela ne porte à conséquences ni que cela ne reflète la réalité.
Lorsqu’on utilise un OS classique avec un filesystem bien fait trouver la surface des bases de données est assez aisé. Cependant déterminer la Taille des BDD dans ASM est un peu moins évident.
Par exemple :
Mon ami le N2 m’a appelé en panique : Oulalalalaaaaaa, y’a pu d’place sur +DATA, quoi qu’on fait ?
C’est à peu près à ce moment là, si ce n’était déjà fait, que l’on regrette d’utiliser ASM.
Ce que l’on souhaite faire c’est afficher simplement le nombre de redo log files générés en mode graphiquesous forme de heat-map. Pour ce faire on utilise highcharts qui a le bon goût d’être gratuit pour un usage récréatif et non commercial. Et parce qu’on aime s’amuser on testera aussi avec plotly qui est gratuit tout court.
Pour ce faire, On choisit de séparer le code HTML, du javascript et des données de manière ce que chaque partie de code puisse être réutilisés au maximum.
SQL est pratique mais il est compliqué de produire un script SQL qui s’adapte à toutes les versions de la base oracle ou qui réagit en fonction de certains résultats de requêtes. Cet article pour donner des astuces de scripting afin de gérer des branchements et boucles en pur SQL et de pouvoir créer des scripts adaptifs.
(suite…)
Ce article pour me souvenir des choses utiles à l’installation de Kairos et à son exploitations
Kairos est une application docker qui pertmet de “grapher” des machins et des bidules. Il est pré-configuré pour les performances sur oracle que ce soit avec ASH ou StatsPack ( d’où l’immense intérêt de la chose ).
La requête suivante permets de trouver l’historique des modifications du paramétrage Oracle qui a pu être effectué au niveau de l’instance dans et stocké dans AWR. La rétention des informations est donc équivalente à celle de rétention des snapshots. Si vous utilisez un AWR Warehouse, potentiellement, vous conservez cet historique depuis son initialisation.
select eit
, param
, last_val
, cur_val
, is_def
from ( select end_interval_time eit
, parameter_name param
, lag ( value, 1 ) over ( partition by dbid, instance_number, parameter_hash order by snap_id) last_val
, value cur_val
, isdefault is_def
from dba_hist_parameter natural join dba_hist_snapshot
where dbid = :dbid )
where last_val != cur_val
and last_val is not null
/
La requête nécessite que la variable DBID soit positionnée afin pouvoir requêter aussi bien la base locale que le reository AWR Warehouse. En local on positionnera la bind variable de la manière suivante :
var dbid number exec select dbid into :dbid from v$database /
Avoir l’historique des modifications du paramétrage Oracle permet, surtout lorsqu’on travaille à plusieurs sur une même base de données, d’apporter des éléments de réponse à la question : “Pourquoi mon appli marche-t-elle moins bien depuis 12 jour ?”. Donc savoir accéder à ces informations est une aide précieuse surtout lors d’interventions occasionnelles.