dump qui plante une base

[olivanto]

bonjour,

J'essaie d'importer un dump vers une nouvelle base en 11g.

Le dump se déroule bien jusqu'à l'import d'une table énorme, et là c'est le drame, plus rien ne fonctionne.

J'ai pourtant des tablespaces conséquents, je pensais que cela suffisait, visiblement pas...

J'ai trouvé çà dans le alert.log ; si quelqu'un savait ce que je devrai faire ???

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Errors IN file d:\app\administrateur\diag\rdbms\MABASE\MABASE\trace\jones_arc2_2720.trc:
ORA-19809: limite dépassée pour les fichiers de récupération
ORA-19804: impossible de récupérer un espace disque de 26221568 octets de la limite 4102029312
ARC2: Error 19809 Creating archive log file TO 'D:\APP\ADMINISTRATEUR\FLASH_RECOVERY_AREA\MABASE\ARCHIVELOG\2011_05_09\O1_MF_1_156_%U_.ARC'
ARCH: Archival stopped, error occurred. Will continue retrying
Errors IN file d:\app\administrateur\diag\rdbms\MABASE\MABASE\trace\jones_arc2_2720.trc:
ORA-16038: le journal 3 séquence 156 ne peut pas être archivé
ORA-19809: limite dépassée pour les fichiers de récupération
ORA-00312: journal en ligne 3 thread 1 : 'D:\BASE\MABASE\REDO03.LOG'
Thread 1 cannot allocate new log, sequence 158
Checkpoint NOT complete
  Current log# 1 seq# 157 mem# 0: D:\BASE\MABASE\REDO01.LOG
Thread 1 advanced TO log sequence 158 (LGWR switch)
  Current log# 2 seq# 158 mem# 0: D:\BASE\MABASE\REDO02.LOG
Mon May 09 12:36:26 2011
Errors IN file d:\app\administrateur\diag\rdbms\MABASE\MABASE\trace\jones_arc3_3652.trc:
ORA-19815: AVERTISSEMENT : db_recovery_file_dest_size octets sur 4102029312 sont utilisés (100.00%) ; il reste 0 octets disponibles.

[Pomalaix]

Il faut juste ne pas perdre son bon sens face à une erreur.

Quand on tombe sur un message d'erreur, (par exemple ORA-19809 qui est le premier dans votre liste), on commence par faire une recherche : sur Developpez, dans la doc Oracle, sur Google...

Et bizarrement, ça répondra déjà à 90% de vos problèmes. Le votre en fait partie.

[olivanto]

tout d'abord, merci...

oui, je panique un peu , j'arrive même pas à faire un import...

bon, donc, j'ai

Code :

db_recovery_file_dest_size octets sur 4102029312 sont utilisés (100.00%)

ca fait +4Go... Quel élément de la base cela est-il ?

Je peux bien le passer à plus ;

Code :

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE= xxx SCOPE=BOTH;

Mais j'aurai voulu savoir ce que c'est exactement avant ?

encore, merci.

olivanto en panique...

[Pomalaix]

Il est probable que ce soient les archivelogs qui saturent la zone flash.

A vérifier comme ceci :

Code :

SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;

[olivanto]

merci pour ta requete, mais c'est trop tard pour cette fois.

J'ai tout droppé, et je recrée ma base de test. Je viens de vérifier le paramètre de la taille de la zone flash (encore une grande nouveauté pour moi !:!).

-->Est ce qu'il serait judicieux de
1. désactiver l'archivelogs pendant l'import,
2. et/ou déplacer le répertoire ARCHIVELOGS, qui par défaut se crée dans cette zone ??

merci

[Pomalaix]

Oui, s'il s'agit d'une base de test, on peut envisager de ne pas activer le mode ARCHIVELOG, et / ou de ne pas activer la zone flash, ou encore de stocker les archives en dehors de la zone flash.

[olivanto]

mmh, attend, tu m'inquiètes là...

"Oui, s'il s'agit d'une base de test (...)ou encore de stocker les archives en dehors de la zone flash"

Pourquoi, qu'est ce que cela change que ces archives soient ou pas dans ce répertoire ??

Si on les y laisse, j'imagine que la taille de cette zone flash doit être fabuleuse ?