Les n commandements du DBA

	Info TAFORA
	Méthodes Conseil
	Mon credo Oracle
	Nouveautés
	Expertise technique
	Fiches Techniques
	Séminaires

Technique
	FAQ
Domaines
	DBA
	Tuning
	PL/SQL
Divers
	Varia
	Liens
Contact
	TAFORA
	Radu
	Mail

DBA
Les n commandements du DBA

(C1) Tout le temps les fichiers alert.log tu regarderas !

C’est la moindre de choses. Alert.log contient des informations capitales. Si toute ma vie j’avais fait ceci, j’aurai été prévenu longtemps en avance de bien de petites catastrophes. Que fait en premier le DBA le matin ? Il lave ses dents :-), et ensuite il scrute ses logs.

(C2) Le fichier de contrôle tu multiplexeras !

Il est possible de reconstituer un fichier de contrôle, mais c’est bête de le faire si on ne l’a pas perdu ;-). Garde-fous, la seule manière d’augmenter les paramètres MAX… est de le recréer. Donc, soyez voluptueux avec ceux-ci, et vous serez heureux de ne pas devoir reconstituer ces fichiers, d’autant que leur multiplexage est facile et ils ne sont pas gros. Radu recommande trois fichiers de contrôle.

(C3) Les fichiers REDO LOG tu multiplexeras !

Pour prévenir les pertes intempestives (elles sont toujours intempestives, les pertes ;-) des fichiers redo log, multiplexons-les ! Et pas n’importe comment, sur des cartes contrôleur différentes, ne faites pas le multiplexage sur deux partitions du même disque !

(C4) Des tablespaces auto manageables tu utiliseras ! (8i)

Les tablespaces de type 'management local' sont très intéressantes parce qu’elle réduisent la fragmentation et la population des tables fet$ et uet$. Satellitement, lisez la théorie sur les trois tailles de base des extents dans une base Oracle !

create tablespace jobs_tbs 
  datafile 'M:\db\ulib\jobs_tbs.DBF' size 300M reuse
  extent management local uniform size 160k;

(C5) Les tables non système tu analyseras !

Dans presque vingt pour cent des cas d'optimisation SQL de ma vie, le simple fait d'analyser les tables non système participantes à une requête très longue à amélioré dramatiquement les performances. Pour rappel, analysez vos tables après une modification importante en volumétrie. Vous aiderez l'optimiseur CBO.

(C6) Un tour dans rdbms/admin tu feras !

Ces scripts contiennent une véritable mine d’or d’informations pour les gens curieux. Pendant des années c’était la seule source fiable de documentation pour les packages ORACLE (Les headers de toutes les procédures et fonctions Oracle, même celles cryptées sont lisibles. Des bonnes âmes de chez Oracle ont commenté d’une manière très opulente ces packages, procédures et fonctions. Donc donnez-vous à cœur joie aux recherches dans ce répertoire magique !

La répartition des différents types de fichiers sur disques.

(D0) Avant de vous lancer dans un système RAID, lisez ceci:

http://www.tafora.fr/wp/oracleraid.doc.html

(D1) Les redo log en ligne et redo log archivés tu sépareras !

En effet, en mode Archivelog, ces fichiers sont accédés simultanément, d’ou une contention des accès aux ressources. Au pire, mélanger un redo log avec le multiplex d’un autre.

(D2) Les groupes de redo logs en ligne dans la mesure du possible tu sépareras !

Ceci va diminuer la contention entre les sources de travail de LGWR et ARCH .

(D3) Les différents membres des groupes de redo tu sépareras.

Ceci diminue d’une manière imperceptible les contentions, il s’agit plutôt d’une règle d’élémentaire précaution qui empêche la perte de tous les membres si le disque unique ou ils résident est perdu.

(D4) Les supports des RBS et tables tu sépareras

(D5) Les index et les tables tu sépareras

Il s’agit plutôt d’une latence entre la fin de l’accès aux index et l’accès aux tables associés. Au pire, mélanger des tables avec des index des autres tables

(D6) Les utilisateurs dans d’autre tablespaces (que SYSTEM) tu logeras. Ceci s’applique aux tablespaces DEFAULT et TEMPORARY.

(D7) Les supports des tablespaces temporaires et données (et index) tu sépareras

(D8) Si à bout des disques, la cohabitation des tablespaces temporaires et des rollback segments tu accepteras.

(D9) Les redo log en ligne seuls sur leurs disques tu laisseras. C’est plus simple que de dire qu’ils ne seront pas logés avec RBS, tables ou index.

(E1) Deux tablespaces pour les rollback segments sur des disques différentes tu auras.

En effet, comme ORACLE alloue aux transactions des RBS d’une manière quasi circulaire (segments pris dans l’ordre stipulée dans init.ora), statistiquement nous diminuons ainsi les contentions disque.

Le deuxième effet de ce choix est évident quand vous perdrez un tablespace RBS. Mieux vaut avoir un deuxième sous le coude pour le procès de restauration.

(E2) La cible des fichiers d’export avec rien tu ne mélangeras.

Comme l’export utilisent les algorithmes ORACLE (lecture), il semblerait que cette règle n’est pas nécessaire, mais pensons aux options CONSISTENT=Y qui provoque des écritures massives dans des RBS si activité soutenue sur la base.

Quelques règles de gestion
Commentez votre code

(R1) Personne n’est parfait. Il y une seule chose qui est pire que comprendre le code que quelqu’un a écrit : comprendre son propre code quelques mois plus tard, donc commentez vos scripts. Il n’est pas indispensable celui qui ne commente pas son code ;-) Il est suicidaire.

Ayez vos scripts

Ayez sous le coude quelques scripts qui sauvent:

(R2) Script qui extrait la géographie de la base

(R4) Script qui recrée les fichiers de contrôle

(R5) Script pour lancer un backup

(R6) Script(s) qui analysent les perfs à votre sauce

(R7) Script qui recrée les tablespaces UNDO, DEFAULT, etc (9i)

Taches quotidiennes
Instances fonctionnelles ?

(F1) Vérifier que les instances censées de tourner tournent. Un simple script SQL suffit, mais un script de prise de mesures est mieux. L’automatisme de cette action représente un plus.

Alert.log

(F2) Vérifier alert.log correspondant à chaque instance. Rechercher au moins les ORA-. Alert.log est situé dans le répertoire background_dump_dest spécifié dans init.ora ou dans spfile.ora (répercuté en v$parameter).

Taile des fichiers Log

(F3) Pensez à réduire les tailles des fichiers log qui tendent de devenir monstrueuses. Utilisez un script quotidien pour vérifier que leurs tailles ou leur nombre ne depasse une limite (pistée au pif ;-)).

Pensez à arrêter le traçage du listener pendant l'opération de purge du listener.log

Backups

(F4) Vérifier que les backups et/ou exports se sont bien déroulés.

Bandes

(F5) Vérifier que ce qui est censé d’être copié sur bande l’est.

Vérifier les ressources

Espace libre (free space)

(F6) pour chaque instance, vérifier que l’espace libre est suffisant pour les croissances régulières _et_ pour les croissances exceptionnelles. La vérification de l’espace libre doit tenir compte des tablespaces autoextensibles et fichiers temporaires. Vérifier donc l’espace libre vu par le système.

Rollback segments

(F7) Leur status doit être ONLINE à l’exception du ROLLBACK_BIG (vous savez à quoi je me refere). Il est de bon ton de mesurer les activités dans les RBS pour mieux calculer leurs tailles (V$ROLLSTAT).

Segments

(F8) Cherchez les segments dans les tablespaces ‘normaux’ (dictionary managed) qui ont trop d’extents, pour éviter les gestions coûteuses de FET$ et UET$. Regardez si le mot clé UNLIMITED est toujours nécessaire dans la storage clause des segments.

Identifier l’explosion suivante

(F9) Rendu vétuste (mais pas obsolète) par maxextents unlimited du tablespace ET segments, la recherché des segments qui ne pourront pas recevoir un extent next par manqué d’espace (TABLESPACE) est nécessaire.

Contentions

(G1) Vérifier les contentions CPU, mémoire, disques, réseau.

Standby database (data guard)

(G2) Si vous avez implémenté la standby, vérifiez son bon fonctionnement. Si les redo logs sont appliqués manuellement, appliquez les ! Si le mécanisme est automatisé, vérifiez son bon déroulement.

Réplication

(G3) Si vous avez implémenté la réplication, pensez à la vérifier. Pensez à fliquer les jobs Oracle et à vérifier que les tables répliquées le sont toujours (comparaison de leurs contenu, etc.).

Stats


Copyright © 1998-2002 Radu Caulea, TAFORA	MAJ 06/11/2006
Commentaires et suggestions radu[CHEZ]tafora.fr