LOGGING / NOLOGGING

Bonjour,

base Oracle 8.1.7 sur AIX 4.3.3.

Je travaille sur un base de reporting, qui est exclusivement utilisée le jour en select.
Mais la nuit, des batchs tournent d'update, insert et delete.

Sachant que :
La politique de sauvegarde est une sauvegarde à froid quotidienne.
La politique de restauration en cas de crash d'un disque est une restauration de la sauvegarde de la veille.
La base n'est pas en mode archive.
Nous avons des soucis de ralentissement des deletes.

Est-ce que le fait de passer certains objets en nologging pourrait n'avoir aucun inconvénients/risques ? Si oui, cela pourrait-il booster les performances des deletes d'une manière très significative ?

Merci pour votre réponse.

Cordialement,

Pourquoi tes deletes sont'ils long? que disent les trace ?

Vu la politique de sauvegarde /restauration ( perte d'une journée de travail ) , tu n'a pas besoin d'avoir des objets et tablespaces en logging .

Avant d'envisager les solutions extrêmes, il convient d'analyser d'abord le code SQL.
est-il optimisé ?
est-il optimisable ?
la table sur laquelle s'exécute les DELETE supporte t-elle un ou plusieurs triggers ?
avez-vous envisagé de supprimer les index avant l'ordre DELETE puis la reconstruction après ?

en mode NOARCHIVELOG le paramètre LOGGING n'a aucun intérêt :?, néanmoins je doute que le passage en NOLOGGING améliore sensiblement les performances.

Il faudrait plutôt s'interroger la pertinence des DELETE... des TRUNCATE pourraient être plus intéressant.

La sauvegarde est faite avant ou après les UPDATE/INSERT/DELETE ?

Il faut avant tout se fixer un objectif, pourquoi c'est long ? En quoi c'est génant ? Combien de temps faut-il gagner ?

passer de 2h à 1h si de toute façon personne n'utilise la base pendant 3h n'a aucun intérêt, c'est dépensé du temps et de l'argent pour rien ;)

Tout d'abord, merci pour vos réponses rapides :D

Si le fait de ne pas être en mode archive log entraine l'inutilité de l'option logging, autant que je l'enlève !

Par contre que se passe-t-il lors d'un arrêt brutal de la base (shutdown abort) ? Le recover effectué derrière ne rejoue pas les redologs ? Dans ce cas la si mes tables ne sont pas en logging, ais-je une possible perte d'information ?

Enfin, les deletes sont fait par informatica (select sur une base et delete correspondant dans ma base reporting). J'ai un exemple d'une table de 30 millions de lignes(une trentaine de champ, et un index unique de 26 champs ... oui c'est pas top). Je vais plus vite au delete avec l'index que sans ... car il utilise l'index lors du delete. (j'ai testé avec un index sur 1 seul champ à la place, et cela revient au même)

La sauvegarde est faite avant les batchs de nuit.

Merci pour vos réponses.

des triggers sur la table ?

Je peux en mettre, mais je ne vois pas où vous voulez en venir? 8O

Citation:

---

Envoyé par SheikYerbouti

des triggers sur la table ?

---

Ou FK avec DELETE CASCADE probablement ;)

Un shutdown abort alors que tu n'es pas en archive log reste de toute façon suicidaire :?

Citation:

---

Envoyé par jokos2000

Je peux en mettre, mais je ne vois pas où vous voulez en venir? 8O

---

Eventuellement, la désactivation des triggers ou DELETE CASCADE peut faire gagner un temps précieux :)

Oki, pardon, je n'avais pas compris :lol:

Je n'ai pas de trigger sur la table et pas d'option delete cascade sur les tables :(

En fait, je penche plutôt sur un mauvais paramétrage informatica (par exemple fréquence de commit...)

Mais vous m'assurez que je peux mettre toute la base en nologging ? :lol:

NOLOGGING limite les entrées dans les redos (j'admets ne pas bien saisir le manque à gagner) or l'utilisation des redos est très limitée lorsque tu n'es pas en ARCHIVELOG... conclusion le NOLOGGING suffit.

LOGGING permet de récupérer un shutdown abort plus facilement ;)

Donc, c'est quand même assez risqué de le supprimer...

http://asktom.oracle.com/pls/ask/f?p=4950:8:7603986834852956483::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:6090310800574 ;)

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/tables.htm#8262

C'est clair que mettre toute la base en no logging, ce serait plus que moyen, mais pourquoi ne pas activer la journalisation uniquement sur les tables, pas sur les indexes (au pire, dans le cas d'un crash, il faudra les rebuilder mais on n'aura rien perdu).

Merci pour vos réponses.

En fait, pour le logging/nologging, dans metalink (http://metalink.oracle.com/metalink/plsql/ml2_gui.startup)
il est spécifié :

Citation:

---

time to insert into a large table or index or LOB can be reduced dramatically

---

Ce qui me fait penser que je peux gagner pas mal en rapidité aussi avec les update/delete ?

dans la doc (lien donné au dessus) c'est bcp plus mitigé :

Citation:

---

In general, the relative performance improvement of specifying NOLOGGING is greater for larger tables than for smaller tables. For small tables, NOLOGGING has little effect on the time it takes to create a table. However, for larger tables the performance improvement can be significant, especially when you are also parallelizing the table creation.

---

Comme le dit Leo, le plus pertinent serait un NOLOGGING uniquement sur les indexes ;)

Vendu pour les indexes en nologging :lol:

Je vais tester tout cela.

Merci à vous !