Discussion :

[hkhan]

Bonjour, j'espere que ma question n'est pas "trop à cote de la plaque"...

Si on a un tablespace dédié pour des index, est ce que cela peut etre interessant de le mettre en mode nologging ?
(cela voudrait dire que lors des restaurations, il faut reconstruire les index je pense)

Mais est ce que lors d'operations d'ajout/suppression/mise à jour sur des colonnes indexées, avec un tablespace d'index en mode nologging, on aurait moins de charges sur les redo log ?


et presque sans transition : lors d'une sauvegarde base ouverte, "on" m'a dit qu'il etait inutile de sauvegarder les fichiers redo log... (que les derniers archivelog...), par contre qu'il fallait sauvegarder les fichiers du tablespace undo... Est ce juste ?
(bien sur chaque tbs en mode backup pendant la sv de son/ses fichiers)


voila

[LeoAnderson]

Imaginons ce qui se passerait.... :-)

Etat initial : base de données Ok, différents TBS Ok, TBS des indexes OK en no logging (de plus, on considèrera que tous les indexes sont no logging)
Sauvegarde à froid disponible et valide
Intégralité des archive log disponible.

**** INCIDENT : Manque de pot, sur le fichier des indexes (sinon, c'est pas drôle)

On restaure donc la sauvegarde (uniquement le fichier endommagé)

On essaie de démarrer la base : "need media recovery"
Donc, on tente un recover mais comme les archive log ne contiennent rien pour le TBS, il ne se passe rien et on conserve la désynchronisation entre le fichier des indexes et les autres et on est coincés.
Il faut donc faire un offline drop, re-créer le TBS, et recréer les indexes, ce qui implique d'avoir les scripts de création sous la main...

donc, éventuellement ça peut être un risque à prendre de passer les indexes en no logging ponctuellement : lors d'une grosse mise à jour de données, par exemple, en prenant soin de faire une sauvegarde des script de création et en repassant en logging juste après !

[hkhan]

c'est bien ce que je craignais.... ma question est un peu a cote de la plaque...

je pensais que si crash du tablespace des index survenait, il me "suffisait" apres de lancer mon script de creation du tablespace des index et de rebuilder tous les index...
dsl et merci pour les info !!

[orafrance]

oui c'est ça... mais vous ne pourrait pas faire de restauration à partir des archive logs par contre

[hkhan]

oui c'est ça... mais vous ne pourrait pas faire de restauration à partir des archive logs par contre

En quoi cela peut il etre genant que je ne puisse faire ma restaure des index a partir des archivelog ? sachant qu'ils (les index ) ne sont pas perdu (grace à la commande rebuilt)...
Je pense que la restauration risquerait d'etre plus longue et avec qlq contraintes (script creation de mon tablespace index + rebuilt tous les index), mais je ne suis pas ds un environnement où la prod doit etre restauree ds le delai le plus court possible


Par contre, si je me trompe pas, mes opérations de lmd seraient un peu plus "rapide" car mes RL seront un peu moins solicites... Est ce que j'ai juste ? :p

voila

[orafrance]

Ce n'est absolument pas génant mais comme tu le soulignes, il faut faire attention au temps de restauration par rapport au temps de création

Effectivelement les ordres seront plus rapides et le NOLOGGING est d'ailleurs conseillé lors des migrations pour les gros imports de données