LOGGING/NOLOGGING aide à gérer l'activation des écritures de chemin direct afin de réduire la génération de REDO et UNDO. C'est l'une des nombreuses façons de contrôler l'équilibre délicat entre la capacité de restauration et les performances.
Informations générales sur l'architecture Oracle
Rétablir c'est ainsi qu'Oracle assure la durabilité, le "D" dans ACID. Lorsqu'une transaction est validée, les modifications ne sont pas nécessairement stockées proprement dans les fichiers de données. Cela maintient les choses rapidement et permet aux processus d'arrière-plan de gérer une partie du travail. REDO est une description du changement. Il est stocké rapidement, sur plusieurs disques, dans un journal "muet". Les modifications sont rapides et si le serveur perd de l'alimentation une microseconde après le retour de la validation, Oracle peut parcourir les journaux REDO pour s'assurer que la modification n'est pas perdue.
ANNULER aide Oracle à assurer la cohérence, le "C" dans ACID. Il stocke une description de la façon d'annuler la modification. Ces informations peuvent être nécessaires à un autre processus qui lit la table et qui a besoin de savoir quelle est la valeur utilisée être à un moment plus ancien.
Écritures de chemin direct ignorez REDO, UNDO, le cache et certaines autres fonctionnalités, et modifiez directement les fichiers de données. Il s'agit d'une option rapide mais potentiellement dangereuse dans de nombreux environnements, c'est pourquoi il existe tant d'options déroutantes pour la contrôler. Les écritures de chemin direct ne s'appliquent qu'aux INSERTS et uniquement dans les scénarios décrits ci-dessous.
Si vous ne faites rien, l'option par défaut est la plus sûre, LOGGING.
Les nombreuses façons de contrôler les écritures de chemin direct
LOGGING/NOLOGGING est l'une des nombreuses options permettant de contrôler les écritures de chemin direct. Regardez ce tableau de Demandez à Tom pour comprendre comment les différentes options fonctionnent ensemble :
Table Mode Insert Mode ArchiveLog mode result
----------- ------------- ----------------- ----------
LOGGING APPEND ARCHIVE LOG redo generated
NOLOGGING APPEND ARCHIVE LOG no redo
LOGGING no append ARCHIVE LOG redo generated
NOLOGGING no append ARCHIVE LOG redo generated
LOGGING APPEND noarchive log mode no redo
NOLOGGING APPEND noarchive log mode no redo
LOGGING no append noarchive log mode redo generated
NOLOGGING no append noarchive log mode redo generated
FORCE LOGGING peut remplacer tous ces paramètres. Il y a probablement d'autres commutateurs que je ne connais pas. Et bien sûr, il y a les nombreuses limitations qui empêchent le chemin direct - déclencheurs, clés étrangères, cluster, tables organisées en index, etc.
Les règles sont encore plus restrictives pour les index. Un index sera toujours générer REDO pendant les instructions DML. Uniquement les instructions DDL, comme CREATE INDEX ... NOLOGGING ou ALTER INDEX ... REBUILD sur un index NOLOGGING ne générera pas REDO.
Pourquoi y a-t-il tant de façons ? Parce que la récupérabilité est extrêmement importante et que différents rôles peuvent avoir des points de vue différents sur la question. Et parfois, les décisions de certaines personnes doivent prévaloir sur d'autres.
Développeurs décider au niveau de l'instruction, "Insert Mode". Beaucoup de choses étranges peuvent arriver avec un /*+ APPEND */ indice et les développeurs doivent choisir avec soin quand l'utiliser.
Architectes décider au niveau de l'objet, "Mode Table". Certaines tables, quelle que soit la vitesse à laquelle un développeur souhaite y insérer, doivent toujours être récupérables.
Administrateurs de bases de données décider au niveau de la base de données ou du mode tablespace, "Archive log" et FORCE LOGGING. Peut-être que l'organisation ne se soucie pas de récupérer une base de données spécifique, alors réglez-la sur le mode NOARCHIVELOG. Ou peut-être que l'organisation a une règle stricte selon laquelle tout doit être récupérable, alors définissez l'espace de table sur FORCE LOGGING.
