[8.1.7] Cas intéressant

[apersonnat]

Bonjour,

Je suis confronté depuis quelques jours au rafraichissement d'une vue matérialisée posant problème.

Je passe les détails, voici le sujet de mon post :

Hier un refresh de VM sur une table de 10 million d'enregistrements à été lancé, ce matin le traitement était toujours en cours et plombait les performances de la base.

Arrêt du traitement, 38000 blocks utilisés par les RBS, la transaction part en rollback, évidemment cette opération nécessite un peu de temps ... arrêt de la base, bien sur l'immediate ne passe pas (transaction en cours de rollback).

Abort de la base, la session liée au rollback et DBWR étant en train de bosser je fais un kill -9 (après avoir attendu quelques minutes) des deux process.

Startup de la base, Oracle effectue son crash recovery en 1h00

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Beginning crash recovery of 1 threads
Mon May 26 09:49:47 2008
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 GROUP 1 Seq 12261 Reading mem 0
  Mem# 0 errs 0: /oradatD30/VISP/redo11.rlg
Mon May 26 09:49:58 2008
Recovery of Online Redo Log: Thread 1 GROUP 2 Seq 12262 Reading mem 0
  Mem# 0 errs 0: /oradatD30/VISP/redo21.rlg
Mon May 26 10:40:58 2008
Thread recovery: finish rolling forward thread 1
Thread recovery: 10800 DATA blocks READ, 8281 DATA blocks written, 177863 redo blocks READ
Mon May 26 10:41:18 2008
Crash recovery completed successfully

Je lance ensuite un arrêt/relance de la base (sujet à débat), rien ne se passe, je repasse un abort pour retomber dans la même problèmatique a savoir deux process sont en cours une session et DBWR, pourtant je n'avais aucun traitement en cours de rollback ..

Je lance le startup et trois heurs plus tard, j'obtiens un succefully completed :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
Beginning crash recovery of 1 threads
Mon May 26 10:59:25 2008
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 GROUP 3 Seq 12263 Reading mem 0
  Mem# 0 errs 0: /oradatD30/VISP/redo31.rlg
Mon May 26 14:04:33 2008
Thread recovery: finish rolling forward thread 1
Thread recovery: 20037 DATA blocks READ, 18593 DATA blocks written, 83732 redo blocks READ
Mon May 26 14:04:49 2008
Crash recovery completed successfully

Je viens de relancer un shutdown immediate qui est toujours en cours après deux heures de traitement.

A noter que le 'shuddown immediate' n'apparait pas encore dans l'alert.log

Code :

1
2
3
4
5
6
7
 
Mon May 26 14:07:33 2008
ARC1: Archival started
ARC0: Completed archiving log# 1 seq# 12265
Mon May 26 14:52:56 2008
Restarting dead background process SNP0
SNP0 started WITH pid=8

Je pense que SMON doit faire un peu de nettoyage enfin je suppose ..


Si vous avez déjà rencontré ce problème, je suis preneur ;-)

Cdt,
A.Personnat

[orafrance]

c'est très simple, quoiqu'il arrive Oracle est obligé de faire un rollback. Si tu fais un abort, le rollback est lancé au démarrage.

cf fast_start_parallel_rollback

[apersonnat]

Il me semblait que lorsqu'une base tombait (l'équivalent d'un abort), Oracle effectuait son rollback lors du crash recovery, ce qui explique la durée relativement longue de l'operation.

Et lorsque j'ai requêté sur la v$transaction je n'avais aucune transaction en cours, donc je ne vois pas ce qui bloque Oracle lorsque je lance un shutdown immediate (l'odre sql ne passe même pas dans l'alert.log)

Curieux non ? mais bloquant tout de même ;-)

[orafrance]

non, le recovery rejoue les redos mais le rollback est à part...

[apersonnat]

Mais dans ce cas, comment se fait il que je n'ai rien dans la v$transaction ?
Si tel était le cas, j'aurais le champ used_ublk indiquant le nombre de blocks à 'rollbacker' .. non ?

[orafrance]

non ta transaction est terminé, c'est juste un déplacement de bloc...

[apersonnat]

Effectivement la transaction en rollback après kill de session n'est pas dans v$transaction mais dans v$fast_start_transaction ..

Domage cela m'aurait permis d'éviter quelques soucis mais bon le principal c'est de capitaliser et de ne pas refaire la même erreur deux fois ;-)

En revanche je ne comprends pas lorsque tu dis c'est juste un déplacement de blocks, pourrais-tu stp developper un peu ?

Merci,
A.Personnat

[orafrance]

quand tu modifies une donnée, les blocs originaux sont copiés dans les rollbacks avant d'être mis à jour dans le datafile. Quand tu fais un rollback alors il faut restaurer les blocs et faire la copie dans l'autre sens.

[apersonnat]

Je m'aperçois que j'ai souvent des problèmes de checkpoint not complete; j'ai rajouté des groups mais sans grand changement.

En fait j'ai le log_checkpoint_interval à 100000 ce qui me fait avec une taille de bloc OS à 512 (si tel est vraiment le cas) un checkpoint tous les 50Mo ce qui correspond à la taille de mon redo.

Je crois que je devrais peut être diminuer ce paramètre non ?

[orafrance]

le nombre de groupe ne change rien à la fréquence de switch, ton problème vient plus probablement de la taille des redos (trop petite).