enfin !

Environnement : HPUX ( mais peut arriver ailleurs je pense ).

Symptomes :

Dans mon bloc PL/SQL j’ai ces ligne :

h1 := dbms_datapump.open (operation => ‘EXPORT’, job_mode => ‘SCHEMA’, job_name => ‘EXPORT’ , version => ‘COMPATIBLE’);

dbms_datapump.set_parallel(handle => h1, degree => 1);

dbms_datapump.add_file(handle => h1, filename => ‘EXPDAT.LOG’, directory => ‘DATA_PUMP_DIR’, filetype => 3);

dbms_datapump.metadata_filter(handle => h1, name => ‘SCHEMA_EXPR’, value => ‘IN(’‘TOTO’‘,’TOTO2‘‘)’);

dbms_datapump.add_file(handle => h1, filename => ‘EXPDAT%U.DMP’, directory => ‘DATA_PUMP_DIR’, filetype => 1);

dbms_datapump.start_job(handle => h1, skip_current => 0, abort_step => 0);

dbms_datapump.detach(handle => h1);

Et ca me donne ceci :

ORA-12012: error on auto execute of job 2345167
ORA-31626: job does not exist

Frustrant non ?

La chose a savoir : les commandes datapump on besoin d’être dans leur propre transaction … c’est bête mais c’est comme ca !

La solution :

begin
h1 := dbms_datapump.open (operation => ‘EXPORT’, job_mode => ‘SCHEMA’, job_name => ‘EXPORT’ , version => ‘COMPATIBLE’);
end;

begin
dbms_datapump.set_parallel(handle => h1, degree => 1);
end;

begin
dbms_datapump.add_file(handle => h1, filename => ‘EXPDAT.LOG’, directory => ‘DATA_PUMP_DIR’, filetype => 3);
end;
dbms_datapump.metadata_filter(handle => h1, name => ‘SCHEMA_EXPR’, value => ‘IN(’‘TOTO’‘,”TOTO2‘‘)’);
begin
dbms_datapump.add_file(handle => h1, filename => ‘EXPDAT%U.DMP’, directory => ‘DATA_PUMP_DIR’, filetype => 1);
end;
dbms_datapump.start_job(handle => h1, skip_current => 0, abort_step => 0);
begin
dbms_datapump.detach(handle => h1);
end;

Pour les fanas de lecture Doc ID n° 459419.1

a+

Le log emagent.trc dans C:\oracle\ora102\machine_SID\sysman\log

affiche :

2008-09-01 01:04:22 Thread-1596 ERROR upload: Failed to upload file B0000015.xml, ret = -2

2008-09-01 01:04:22 Thread-1596 ERROR upload: 3 Failures in a row for B0000015.xml, we give up

L’agent n’arrive pas a uploader des fichiers de plus de 512Ko ( bug … sous certaines conditions ).

éditer le fichier C:\oracle\ora102\machine_SID\sysman\config\emd.properties

et régler : UploadFileSize=512

arrêter la console et purger dans C:\oracle\ora102\machine_SID\sysman :

NE PAS PURGER LES REPERTOIRES, QUE LES FICHIERS

sysman\emd\lastupld.xml

sysman\emd\state\*

sysman\emd\upload\*

sysman\recv\errors\*

sysman\recv\*

et relancer le tout

Symptômes :

sys@TOTO.WORLD> exec DBMS_AQADM.DROP_QUEUE_TABLE(’TOTO.LAQUEUE’);
BEGIN DBMS_AQADM.DROP_QUEUE_TABLE(’TOTO.LAQUEUE’); END;

*
ERREUR à la ligne 1 :
ORA-24002: QUEUE_TABLE TOTO.LAQUEUE n’existe pas
ORA-06512: à “SYS.DBMS_AQADM_SYS”, ligne 3013
ORA-06512: à “SYS.DBMS_AQADM”, ligne 197
ORA-06512: à ligne 1

Cause :

La cause de tout ça, un import / export un peu buggé sur Oracle 9i pour ceux que ca intéresse.

Notre document de travail : Note:203225.1

Bien bien bien … en gros le dictionnaire est corrompu, soit la table n’existe plus mais la queue si, ou inversement.

Si la queue est restée mais que la table n’est plus la alors on peut tenter de forcer la suppression de la queue :

sys@TOTO.WORLD> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=> ‘TOTO.LAQUEUE’,FORCE => TRUE);

Mais en l’occurence mon problème est que la queue n’existe plus, mais la table si … alors ca se complique …

On commence par nettoyer tout ce qui a un rapport avec la queue :

SELECT object_name, object_type FROM user_objects WHERE object_name like ‘%TOTO%’;

.. aïe .. aucune ligne sélectionnée

si la requête renvoie des lignes, alors dropper les objets.

ALTER SESSION SET EVENTS ‘10851 trace name context forever, level 2′;

Attention , on passe au ménage sauvage, sauvegardez la base avant !

DROP TABLE TOTO CASCADE CONSTRAINTS;

DROP TABLE AQ$_TOTO_<X> CASCADE CONSTRAINTS; ( si les queues existent, vérifier dans dba_objects )

Et voili voila !

a+

 SID|USERNAME      |OSUSER        |TY|LKMODE       |DESCRIP                                           |       SEC|  Blocking|REQMODE
----|--------------|--------------|--|-------------|--------------------------------------------------|----------|----------|-------------
  20|David         |David         |TM|Row-X (SX)   |Table David      .TOTO                            |         3|         0|
  18|David         |David         |TM|Row-X (SX)   |Table David      .TOTO                            |         6|         0|
  20|David         |David         |TX|None         |RBS RS_1, Slot 41 Wrap# 791759                    |         3|         0|Exclusive (X)
  18|David         |David         |TX|Exclusive (X)|RBS RS_1, Slot 41 Wrap# 791759                    |         6|         1|

Voila c’est plutôt génant … maitenant imaginons que nous avons besoin de savoir sur quelle ligne le verrou est placé :

David      @REF.WORLD> r
  1  select do.object_name,row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,

     dbms_rowid.rowid_create ( 1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW# )
  2  from v$session s, dba_objects do
  3* where sid=20 and s.ROW_WAIT_OBJ# = do.OBJECT_ID

OBJECT_NAME|ROW_WAIT_OBJ#|ROW_WAIT_FILE#|ROW_WAIT_BLOCK#|ROW_WAIT_ROW#|DBMS_ROWID.ROWID_C
-----------|-------------|--------------|---------------|-------------|------------------
TOTO       |        16625|            13|         168237|           14|AAAEDxAANAAApEtAAO

Pas mal!

on n’a plus qu’a aller voir la ligne :

David      @REF.WORLD> select * from TOTO where ROWID = 'AAAEDxAANAAApEtAAO';
        ID|TEST
----------|----------
        11|TEST

Lors de l’ajout du composant OleDB :

The procedure entry point longjmp could not be located in the dynamic link library orauts.dll

Le point d’entrée de la procédure longjmp est introuvable dans la bibliothèque de liaisons dynamique orauts.dll

Version : 10.2.0.1 10.2.0.2 10.2.0.3

Solution :

Il s’agit d’un problème de version sur OUI lorsque vous ajoutez des composants en plus sur un ORACLE_HOME déjà patché

Il faut lancer le setup.exe dans $ORACLE_HOME/oui/bin et ensuite choisir sa source xml dans le répertoire d’install.

Voila ! a+

En premier, il fait créer une table ou les plans seront stockés ( PLAN_TABLE ) .

C’est pas compliqué :

system@DB.WORLD> @?/rdbms/admin/utlxplan.sql

Table créée.

Après rien de complexe non plus :

explain plan for <<le code SQL>>

Soit par exemple :

system@DB.WORLD> explain plan for select * from v$session;

Explicité.

La encore rien de transcendant …

Et pour finir :

system@DB.WORLD> @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
—————————————————————————————————-
Plan hash value: 319272779

——————————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 1134 | 0 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 1 | 1134 | 0 (0)| 00:00:01 |
|* 2 | FIXED TABLE FULL | X$KSUSE | 1 | 925 | 0 (0)| 00:00:01 |
|* 3 | FIXED TABLE FIXED INDEX| X$KSLED (ind:2) | 1 | 209 | 0 (0)| 00:00:01 |
——————————————————————————————–

Predicate Information (identified by operation id):
—————————————————

2 - filter(”S”.”INST_ID”=USERENV(’INSTANCE’) AND BITAND(”S”.”KSSPAFLG”,1)<>0 AND
BITAND(”S”.”KSUSEFLG”,1)<>0)
3 - filter(”S”.”KSUSEOPC”=”E”.”INDX”)

17 ligne(s) sélectionnée(s).

Voili voilou !

a+

Comme le bug de ce blog est quand même d’auto alimenter ma mémoire pour m’éviter de rechercher la même chose 100 fois, nous allons donc trouver une solution a ce problème déroutant.

[Oracle]/home/oracle>sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Mon Jul 30 14:22:08 2007

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

ERROR:
ORA-12547: TNS:lost contact

Enter user-name:webkins

Ne cherchez pas, aucun log nulle part, il faut aller se battre avec Metalink pour trouver que le problème est la :

[Oracle]/home/oracle>/usr/sbin/kmtune | grep maxd
maxdsiz 0×10000000 - 0×10000000
maxdsiz_64bit 0×40000000 - 0X40000000

Une verif sur les paramètres noyau de votre HPUX, et hop tout est résolu !

2007-06-18 13:55:44,380 [JobWorker 23218:Thread-19] ERROR jobs.pingCfmEMDDown executeCommand.313 - pingCfmEMDDown: Throwable caught null
2007-06-18 13:56:09,899 [EMUI_13_56_09_/console/monitoring/hostOverview$ctxType=Hosts$type=host$target=monserveur] ERROR host.HostOverviewDataObject getLogonInfo.2343 -
java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:121)

Ou alors :

javax.net.ssl.SSLException: SSL handshake failed: SSLIOClosedOverrideGoodbyeKiss

Cause :

Allez savoir pourquoi, il s’agit d’un problème de configuration du proxy de votre console … du moment que le proxy est configuré pour la partie patch, la console va tenter de l’utiliser pour ses opérations avec les agents .

Solutions :

1- Supprimer la configuration du proxy

=> pour cela, allez en haut sur “Setup”

=> ensuite : “patching Setup”

=> puis proxy, mettre “direct connection to the internet”

2- Mettre votre domaine ( ou la machine ) dans la liste des exclusions.

=> Dans le même endroit

=> rajouter .domaine.com ou machine.domaine.com dans “Don’t proxy for”

Ensuite on relance !

3- Ca continue ?

=> Banzaï !

=> sqlplus SYSMAN@REPOSITORY

=> TRUNCATE TABLE MGMT_URL_PROXY; commit;

a++

Metalink note Note:415035.1

Tout d’habord il faut citer Tom Kyte :

“Unless you have a real reason to use MTS – don’t.” ( plagié sur http://www.dba-oracle.com )

…

Ensuite créer une base 10g avec DBCA et jeter un oeuil aux paramètres :

NAME |VALUE
dispatchers |(PROTOCOL=TCP) (SERVICE=SID01XDB)

shared_servers |1
shared_server_sessions |

max_shared_servers |

Nous avons donc, une instance avec le MTS activée … mais pas de limite sur le nombre de process..

Comment ne pas récuperer le beurre, ni l’argent du beurre.

a++