03113: end-of-file on communication channel [Résolu]

[skuatamad]

Bonjour à tous,

Je voulais répondre à une question sur le forum mysql quand j'ai rencontré le bug ORA-03113: end-of-file on communication channel.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
WITH the Partitioning, OLAP, DATA Mining AND Real Application Testing options
 
SQL> WITH t AS (
SELECT 5 AS counter, to_date('23/02/2011','dd/mm/yyyy') AS time FROM dual union ALL
SELECT 6, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
SELECT 5, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
SELECT 12, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
SELECT 36, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
SELECT 8, to_date('01/03/2011','dd/mm/yyyy') FROM dual
)
SELECT *
  FROM t
  JOIN (
        SELECT counter, count(DISTINCT time) AS nb_time
          FROM t
         GROUP BY counter
        HAVING count(DISTINCT time) = 2
        ) t1
     ON t.counter = t1.counter;  2    3    4    5    6    7    8    9   10   11   12   13   14   15   16   17   18   19   20  
WITH t AS (
*
ERROR at line 1:
ORA-03113: end-of-file ON communication channel
Process ID: 3664
Session ID: 140 Serial number: 101

Si je crée la table pas de problème, si j'utilise WITH et seulement la sous requête pas de problème...

Je suis sur 11.2.0.1.0, est ce que vous reproduisez ce bug ? même si vous faites le test sur une autre version ?
Je sais que cette erreur veut dire contacter le support... mais comme c'est ma base perso de tests et que je n'ai pas d'accès à metalink :

1/ Je voulais savoir si j'étais le seul à avoir le bug (j'ai eu quelques soucis d'OS ces derniers jours)
2/ si le bug vous impacte aussi, est ce que quelqu'un pourrait se porter volontaire pour ouvrir un case ? (au moins le jeu de test est tout trouvé !)

[edit] je suis sur Fedora14 qui n'est pas un OS certifié... donc vos tests m'intéressent vraiment.

[Pomalaix]

Même souci sous Windows en 11.2.0.1.

Pas de problème sous Windows en 10.2.0.4.

[Waldar]

Je confirme, même problème en 11.2.0.1 sur Windows Server 2003.
Pas de soucis en 11.1.0.7 (toujours Windows Server 2003).

[mnitu]

Je pense que si la requête est ré-écrite comme ci dessous, elle va passer

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
WITH t AS (
  SELECT 5 AS counter, to_date('23/02/2011','dd/mm/yyyy') AS time FROM dual union ALL
  SELECT 6, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
  SELECT 5, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
  SELECT 12, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
  SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
  SELECT 36, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
  SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
  SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
  SELECT 8, to_date('01/03/2011','dd/mm/yyyy') FROM dual
),
t1 AS (
        SELECT counter, count(DISTINCT time) AS nb_time
          FROM t
         GROUP BY counter
        HAVING count(DISTINCT time) = 2
) 
SELECT *
  FROM t 
       JOIN 
       t1
    ON t.counter = t1.counter

[Pomalaix]

Envoyé par mnitu

Je pense que si la requête est ré-écrite comme ci dessous, elle va passer

Perdu !

[Waldar]

Non plus !
C'est vraiment étrange comme bug...

[Pomalaix]

Je me disais que l'assistant de réparation SQL pourrait être utile, eh bien chou blanc !

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
SET long 5000
SET serveroutput ON
 
declare
	id_tache	varchar2(50);
	resu		clob;
begin
	-- suppression de la tâche 'plantage'
	dbms_sqldiag.drop_diagnosis_task('plantage');
 
	-- création de la tâche d'analyse
	id_tache:=dbms_sqldiag.create_diagnosis_task
		(sql_text => Q'!WITH t AS (
		SELECT 5 AS counter, to_date('23/02/2011','dd/mm/yyyy') AS time FROM dual union ALL
		SELECT 6, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
		SELECT 5, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
		SELECT 12, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
		SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
		SELECT 36, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
		SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
		SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
		SELECT 8, to_date('01/03/2011','dd/mm/yyyy') FROM dual
		)
		SELECT *
		FROM t
		JOIN (
			SELECT counter, count(DISTINCT time) AS nb_time
			FROM t
			GROUP BY counter
			HAVING count(DISTINCT time) = 2
			) t1
			ON t.counter = t1.counter!', 
	task_name => 'plantage', 
	problem_type => dbms_sqldiag.problem_type_execution_error
	 );	
 
	-- activation de l'analyse la plus complète
	dbms_sqldiag.set_diagnosis_task_parameter(id_tache, '_SQLDIAG_FINDING_MODE', dbms_sqldiag.SQLDIAG_FINDINGS_ALL);
 
	-- exécution de l'analyse
	dbms_sqldiag.execute_diagnosis_task('plantage');	
 
	-- affichage du résultat
	resu:=dbms_sqldiag.report_diagnosis_task('plantage', dbms_sqldiag.type_text);
	dbms_output.put_line(resu);
 
end;
/

--> No SQL patch was found to resolve the problem.

[skuatamad]

Merci pour vos retours, j'avais essayé la syntaxe t1 dans le WITH et aussi sans l'écriture ANSI.
Par contre je n'ai pas essayé avec un hint materialized.

Ca fait bizarre quand même de tomber sur un bug avec une requête aussi bidon.

[ojo77]

Y a-t-il quelquechose dans l'alert.log ?

[mnitu]

Envoyé par Pomalaix

Perdu !

On ne peut pas gagner à tous les coups…
[Edit]
Je regarderais ce soir.
[/EDIT]

[skuatamad]

C'est "marrant" sans le distinct ça ne bug pas... par contre materialize n'a rien changé.

Ojo77 dans /u01/app/oracle/diag/rdbms/db11gr2/DB11GR2/trace/alert_DB11GR2.log (je met le chemin complet au cas où ce ne soit pas le bon fichier...) :

Code :

1
2
3
4
5
6
Thu Mar 03 20:04:56 2011
Exception [type: SIGSEGV, Address NOT mapped TO object] [ADDR:0x118] [PC:0x1CE6BDB, kkqfppDrv1()+101] [flags: 0x0, count: 1]
Errors IN file /u01/app/oracle/diag/rdbms/db11gr2/DB11GR2/trace/DB11GR2_ora_2801.trc  (incident=32636):
ORA-07445: exception encountered: core dump [kkqfppDrv1()+101] [SIGSEGV] [ADDR:0x118] [PC:0x1CE6BDB] [Address NOT mapped TO object] []
Thu Mar 03 20:04:59 2011
Sweep [inc][32636]: completed

et dans DB11GR2_ora_2801.trc :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Trace file /u01/app/oracle/diag/rdbms/db11gr2/DB11GR2/trace/DB11GR2_ora_2801.trc
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
WITH the Partitioning, OLAP, DATA Mining AND Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
System name:	Linux
Node name:	portable
Release:	2.6.35.11-83.fc14.x86_64
Version:	#1 SMP Mon Feb 7 07:06:44 UTC 2011
Machine:	x86_64
Instance name: DB11GR2
Redo thread mounted BY this instance: 1
Oracle process number: 27
Unix process pid: 2801, image: oracle@portable (TNS V1-V3)
 
 
*** 2011-03-03 20:04:56.938
*** SESSION ID:(136.46) 2011-03-03 20:04:56.938
*** CLIENT ID:() 2011-03-03 20:04:56.938
*** SERVICE NAME:(SYS$USERS) 2011-03-03 20:04:56.938
*** MODULE NAME:(SQL*Plus) 2011-03-03 20:04:56.938
*** ACTION NAME:() 2011-03-03 20:04:56.938
 
Exception [type: SIGSEGV, Address NOT mapped TO object] [ADDR:0x118] [PC:0x1CE6BDB, kkqfppDrv1()+101] [flags: 0x0, count: 1]
 
*** 2011-03-03 20:04:57.074
DDE: Problem KEY 'ORA 7445 [kkqfppDrv1()+101]' was flood controlled (0x2) (incident: 32636)
ORA-07445: exception encountered: core dump [kkqfppDrv1()+101] [SIGSEGV] [ADDR:0x118] [PC:0x1CE6BDB] [Address NOT mapped TO object] []
ssexhd: crashing the process...
Shadow_Core_Dump = PARTIAL

[ojo77]

C'est un bug : Bug 9002336 - Dump in kkqfppDrv1 with DISTINCT & WITH clause

Le contournement est le suivant :

Code :

_optimizer_distinct_agg_transform = false

Sinon il faut télécharger le patch sur My Oracle Support

[mnitu]

Il se casse la gueule pendant le parsing plus précisément dans la transformation de la requête

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
mni@DIANA> WITH t AS (
  2  SELECT 5 AS counter, to_date('23/02/2011','dd/mm/yyyy') AS time FROM dual u
nion ALL
  3  SELECT 6, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
  4  SELECT 5, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
  5  SELECT 12, to_date('23/02/2011','dd/mm/yyyy') FROM dual union ALL
  6  SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
  7  SELECT 36, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
  8  SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
  9  SELECT 5, to_date('01/03/2011','dd/mm/yyyy') FROM dual union ALL
 10  SELECT 8, to_date('01/03/2011','dd/mm/yyyy') FROM dual
 11  )
 12  SELECT *
 13    FROM t
 14    JOIN (
 15          SELECT --+NO_QUERY_TRANSFORMATION
 16             counter, count(DISTINCT time) AS nb_time
 17            FROM t
 18           GROUP BY counter
 19          HAVING count(DISTINCT time) = 2
 20          ) t1
 21       ON t.counter = t1.counter;
 
   COUNTER TIME        COUNTER    NB_TIME
---------- -------- ---------- ----------
         5 23/02/11          5          2
         5 23/02/11          5          2
         5 01/03/11          5          2
         5 01/03/11          5          2
         5 01/03/11          5          2

[skuatamad]

Ah il y a un patch, c'est bien, ce qui est étonnant compte tenu du titre du bug c'est que la sous-requête seule avec le DISTINCT et le WITH fonctionne bien.

Merci à tous pour vos tests et plus particulièrement à ojo et mnitu pour les contournements

Il se casse la gueule pendant le parsing plus précisément dans la transformation de la requête

Mnitu, comment le détermines tu et comment as tu trouvé ce hint, est ce un autre contournement fourni par le support ?

[mnitu]

Envoyé par skuatamad

...
Mnitu, comment le détermines tu et comment as tu trouvé ce hint, est ce un autre contournement fourni par le support ?

Salut Skuatamad,

Non, je n’ai pas de support chez moi .
Mais, si tu trace l’événement 10053, le parsing de la requête, tu retrouveras dans le fichier de trace l’anomalie. Ensuite, en analysant les autres informations situées juste en dessus de l’anomalie on peut comprendre le chemin d’analyse qu’il a pris. Après c’est relativement simple : il reste à trouver le hint qui force un autre chemin ; un hint SQL étant en fait une restriction imposé à l’optimiseur dans l’espace des chemins possibles.

[skuatamad]

Salut Mnitu,

Analyse de la trace 10053, classe !
Je regarderai la trace mais je ne me fais pas d'illusion sur ma capacité à l'analiser, mais ce sera un bon entrainement.
Merci d'avoir précisé ton process d'analyse.