MaXimO NaTioN - Le meilleur des TI!

N'est-ce pas enrageant d'avoir un rebuild d'index qui échoue après 30 minutes car il a manqué d'espace disque dans un tablespace? Si vous êtes comme moi, ça vous enrage! Il y a 2 solutions possibles à ce genre de problème: être très rigoureux et toujours calculer/vérifier ses espaces disques (tablespaces, undo, temp) avant les opérations ou encore utiliser un "resumable timeout" pour nous soutenir.

Avec Oracle, il est possible d'avoir une mesure approximative des modifications ayant eu lieu sur une table depuis la dernière prise des statistiques. La vue SYS.DBA_TAB_MODIFICATIONS (et ses déclinaisons ALL_* et USER_*) est alimentée par la méthode DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO. Cette procédure est invoquée à certains moments clés par Oracle (10g et 11g). Le niveau de statistique (paramètre statistics_level) doit être à TYPICAL ou ALL pour que le monitoring s'effectue.

Dans un schéma/application, il se peut que certains index soient inutilisés et ce, pour différentes raisons. Par exemple, il peut s'agir d'un index redondant (un autre index similaire à celui-ci) dont l'utilisation est inexistante ou encore parce que le prédicat (clause WHERE) ne fait jamais référence aux colonnes de cet index. Il ne faut jamais oublier qu'il y a un coût (overhead) pour Oracle à entretenir chacun de ces index lors d'opérations DML.

Lors d'un traitement critique, il peut être intéressant d'écrire un message de succès ou d'échec dans le fichier alert<SID>.log. Par exemple, si vous avez un trigger « before shutdown » et qu'une exception est levée, il serait intéressant de l'inscrire dans le fichier d'alertage. C'est à l'aide de procédures non documentées d'Oracle du package DBMS_SYSTEM que nous y arriverons.

KSDWRT(<n>,<message>) permet d'écrire un message dans le fichier des alertes ou dans un fichier de trace selon le paramètre <n>.

En programmation, il est souvent utile d'être capable de générer des données non persistantes (i.e. non sauvegardées physiquement) afin de réaliser un traitement en mémoire. Par exemple, nous avons une séquence number(5) qui alimente un identifiant unique dans une colonne avec des valeurs allant de 1 à 99 999. Lors d'insertions, il est possible qu'il y ait des « trous de séquence » dû à une annulation ou une erreur système. Si nous voulons récupérer ces identifiants non utilisés, nous avons quelques options dont l'utilisation des ensembles.

Même si cette facilité existe depuis Oracle 8i, c'est dernièrement que j'ai découvert qu'on pouvait tracer du code Pl/Sql ligne par ligne avec Oracle 10g. En effet, Oracle a mis à la disposition des développeurs un package DBMS_PROFILER qui permet, entre autre, de comptabiliser le nombre d'occurrences et la durée d'un appel précis dans une procédure/fonction/package.

Les prérequis:

1. Se connecter en tant que SYS

Comme Oracle le fait pour certains de ses packages (ex: dbms_system), il peut être intéressant d'encrypter la source d'une procédure, fonction ou package (signature et/ou corps). Pour ce faire, Oracle fournit un utilitaire nommé "wrap.exe". On le retrouve dans le répertoire %ORACLE_HOME%\BIN d'une installation du SGBD Oracle ou encore avec le client 10g.

Tel que mentionné dans mon article précédent, j'ai eu la chance vendredi dernier de visiter le méga ordinateur du consortium CLUMEQ à l'Université Laval.

Hier j'ai eu l'occasion d'utiliser le verrouillage de table pour un problème précis en production. Je devais insérer dans une table X et mettre à jour une table Y en lien avec la table X. Je devais également désactiver un trigger d'insertion et un trigger de mise à jour sur cette table X. J'ai fait ceci dans un bloc pl/sql anonyme.

Il y a déjà quelques mois, j'ai appris sur un article de Slashdot que l'Université Laval a fait construire un méga ordinateur ou data center dans un ancien accélérateur de particules (Van de Graaf). Le consortium CLUMEQ est derrière ce fabuleux projet. Un projet innovateur auquel des spécialistes de Sun Microsystem ont participé.