Discussion :

[md1391]

Bonjour,

Je dois mettre au format XML le contenu de toutes les tables d'un utilisateur Oracle.
est-ce quelque chose de réalisable et fiable??

J'ai trouvé 2 méthodes : avec PL/SQL en utilisant la fonction getXml du package dms_xmlgen mais dans ce cas j'ai des problèmes de taille de lignes et de curseur, l'autre méthode en utilisant XML-SQL Utility pour JAVA.
Cette dernière solution me parait plus fiable, mais dès que je passe la commande sur une table conséquente (80M) j'ai un problème de java.lang.OutOfMemoryError

Merci d'avance pour toute suggestion...

java -Xmx1024M OracleXML getXML -user "ga_adm/adm91" conn "jdbc:oracle:thin:@FESW2K01:1530:GADID" "select * from paie"
Exception in thread "main" java.lang.OutOfMemoryError
<<no stack trace available>>

Autre problème si le nom de la table contient un '#' :
java -Xmx512M OracleXML getXML -user "atms/atms" -conn "jdbc:oracle:thin:@FSW2K02:1530:ATMS" "select * from BOXFROMDESCT#1B"
<?xml version = '1.0'?>
<ERROR>oracle.xml.sql.OracleXMLSQLException: Le caractÞre '#' est interdit dans
un nom de balise XML.</ERROR>

[plaineR]

Et pourquoi pas avec un spool :
http://www.developpez.net/forums/m2048070-4/

[md1391]

Merci, pour la suggestion du spool cela fonctionne.

Seule contrainte , il faut que je vois comment on peut balayer l'ensemble des tables d'une même base..

A suivre.

[plaineR]

Cherche sur le forum, cette question a déjà été posée

[plaineR]

Tiens voici un exemple dont tu peux t'inspirer :
http://www.developpez.net/forums/m1661851-5/

[md1391]

Merci c'est tout à fait à cela que je pensais, il va falloir que je teste un mixage des 2 scripts.
Il ne restera plus que le problème des caractères spéciaux à analyser.

[Vincent Rogier]

Une petite remarque...

Cette méthode appliqué à toute les tables d'un user risque de mettre beaucoup de temps... et de ne pas être viable au final.

J'ai fait des tests avec le script mentionné (utilisant xmlsequence).

Le temps de traitement et les ressource serveur sont très exponentiels avec le nombre de lignes de la table.

J'ai fait mes tests sur 2 tables : T1 de 11.000 lignes et T2 de 80.000 lignes. C'est tables ont la même structure : 12 champs (11 NUMBER et 1 DATE).

Donc, des petites tables bien peu remplies...

J'ai aussi testé le script avec une version modifiée de la requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT  o.getClobval() from table(xmlsequence(cursor(SELECT * FROM X))) o;

au lieu de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM TABLE(xmlsequence(cursor(SELECT * FROM X)));

J'ai par ailleurs codé en 10 minutes 2 applis C (avec OCILIB) :

- l'une N°1 (50 lignes de code) exécute la version de la requête retournant le CLOB (au lieu du XMLTYPE) dans un buffer qui est ensuite redirigé vers un fichier

- l'autre N°2 (80 lignes de codes) fait un simple select * sur la table. Puis loop sur le résultat et grâce aux metas infos des colonnes formate les valeurs dans des balises XML en gérant même les 5 caractères d'échappement XML. Bref, l'ouput est le même qu'avec la solution xmlsequence.

Résultats :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
METHODE                 T1 (11000 rows)          T2 (80.000 rows)        
----------------------------------------------------------------------------------------------
-
SCRIPT INITIAL          36.5 sec.                  ctl+c au bout de 5 minutes
SCRIPT MODIFIE          25.5 sec.                  ctl+c au bout de 5 minutes
APPLI C/OCILIB N°1      10.5 sec                   process killé au bout de 5 minutes
APPLI C/OCILIB N°2      00.6 sec                   4.6 sec
-
-

Pour le traitement sur T2, j'ai du arrêter sql*plus(ctrl+c) et l'appli C qui étaient basé sur xmlreference au bout de 5 à 6 minutes car le processus server d'Oracle avait déja bouffé 800 Mo de mémoire pour traiter la requête ( c'est un serveur Window mais bon c'est une raison !!). J'ai donc arrêté les frais.

Y a pas photos sur les perfs... de 0.6s à 36.5s.... sans commentaire !

Ces petits tests montrent que sur un base de prod, le script proposé est inutilisable....

Il vaut mieux faire une appli C ou java du type "select * from X" et générer le xml soit même.. (80 lignes de code en C....)..

Ou alors même se faire une fonction PL/SQL avec UTL_FILE...mais bon cela pose les problèmes d'accès au FS...


[EDIT : générer le xml à la main est simple. A tout hasard, je te mets le source C de mon appli de test n°2. Tu peux refaire la même chose en PL/SQL...]

[Vincent Rogier]

Merci pour la remarque...

Lors de mes tests j'avais vu qu'effectivement la consommation mémoire était importante si je renais une tables ayant beaucoup d'enregistrements et contenant du varchar.

Je me demande si cette façon de procèder est viable pour archiver annuellement des bases de données de gestion ...

Je vais poursuivre malgrés tout les tests...

Non, ce n'est viable à moins que tu n'aies que des tables minuscules et un très gros serveur .

J'ai modifié le programme C cité dans mon précédent post pour dumper l'ensemble des tables d'un user dans un répertoire en créant un fichier xml par table.

Résultat sur une de mes bases (6 Go utilisés, 830 tables allant de quelques lignes à 10 millions de lignes) :

- 830 fichiers générés en 8 minutes 30 secondes
- le plus gros fichier fait 400 Mo
- l'ensemble des fichiers représente 1,6 Go sur disque

Je pense qu'avec le script sqlplus, cela prendrait plusieurs jours, voir semaines (si le serveur avait une mémoire illimitée)....

Le source du prog est en pièce jointe...

Encore une fois, passe plutôt par une procédure PL/SQL+UTL_FILE (ou DBMS_OUTPUT) ou par un outils tiers ou autre mais le script sqlplus n'est pas adapté à ce que tu veut en faire....

Maintenant si c'est seulement pour faire de l'archivage, tu peux archiver et stocker de manière autre que xml....