Convertion de champs long_raws en blob [Résolu]

[wapette21]

Bonjour,

Je voudrais connaitre les impacts et les ressource nécessaire pour la migration d'un champ long_raw en blob sur une table contenant 2 Millions de ligne.

En faite cette table je souhaite la partitionné pour optimiser les perfs et facilité son exploitation.

Avez-vous une idée de la méthode à mettre en place à une telle action et le temps que cela va prendre ?

Toutes les informations sont bonnes à prendre.

Merci

Yo

[LeoAnderson]

la méthode pas terrible : http://download.oracle.com/docs/cd/B...ctions139a.htm

la méthode élégante :

Code :

ALTER TABLE <latable> MODIFY <lacolonne> blob;

[orafrance]

voila la procédure d'Oracle : How to Convert from Long Raw to BLOB using PL/SQL

Quand au temps, bah seul des tests pourront te permettre de répondre

Pour ceux qui n'aurait pas accès à Metalink :

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
REM long2lob.sql 
REM Version 1.0, last updated 8/8/97 
REM This procedure copies LONG DATA INTO a CLOB, AS described IN 
REM Chapter 21 of _Oracle8 PL/SQL Programming_ BY Scott Urman. 
 
CREATE OR REPLACE PROCEDURE Long2Lob( 
  -- Uses DBMS_SQL to select a LONG column identified by p_LongQuery, and 
  -- returns it in p_CLob. 
  p_LongQuery IN VARCHAR2, 
  p_CLob IN OUT CLOB) AS 
 
  c_ChunkSize CONSTANT INTEGER := 100; 
 
  v_CursorID INTEGER; 
  v_RC INTEGER; 
  v_Chunk VARCHAR2(100); 
  v_ChunkLength INTEGER; 
  v_Offset INTEGER := 0; 
BEGIN 
  -- Open the cursor, define, execute, and fetch. 
  v_CursorID := DBMS_SQL.OPEN_CURSOR; 
  DBMS_SQL.PARSE(v_CursorID, p_LongQuery, DBMS_SQL.V7); 
  DBMS_SQL.DEFINE_COLUMN_LONG(v_CursorID, 1); 
  v_RC := DBMS_SQL.EXECUTE_AND_FETCH(v_CursorID); 
 
  -- Loop over the LONG, fetching c_ChunkSize characters at a time from 
  -- the LONG and adding them to the LOB. 
  LOOP 
    DBMS_SQL.COLUMN_VALUE_LONG(v_CursorID, 1, c_ChunkSize, v_Offset, 
                          v_Chunk, v_ChunkLength); 
    DBMS_LOB.WRITE(p_CLob, v_ChunkLength, v_Offset + 1, v_Chunk); 
    IF v_ChunkLength < c_ChunkSize THEN 
      EXIT; 
    ELSE 
      v_Offset := v_Offset + v_ChunkLength; 
    END IF; 
  END LOOP; 
 
  DBMS_SQL.CLOSE_CURSOR(v_CursorID); 
EXCEPTION 
  WHEN OTHERS THEN 
   -- Clean up, and reraise the error. 
    DBMS_SQL.CLOSE_CURSOR(v_CursorID); 
    RAISE; 
END Long2Lob; 
/

ALTER TABLE c'est bien aussi

[orafrance]

Après réflection, le but étant de partitionner, il faudra de toute façon recréer la table du coup, je te conseille :

Code :

1
2
INSERT INTO tab_partitionnee
SELECT col1, col2, to_lob(col_raw) FROM tab;

[wapette21]

J'avais pense a l'ALTER TABLE j'ai vu qu'il lui fallait le double d'espace pour le faire, je me demander si il pouvait avoir d'autre impact que je ne mesure pas pour moi le seul impact que je vois c'est le temps que cela va prendre et donc l'indisponibilité de la table.

Avez des retours d'expérience ?

Merci de vos réponses

[wapette21]

C'est vrais le but et de partitionner la table mais aussi de anticipé la future migration vers oracle 10g (qui n'utilise plus les long_raw je croit).

Cependant je ne pense pas qu'il est judicieux de réalisé les deux interventions en même temps :

- migration de champ
- partitionnement de la table

Qu’en pensé vous ?


yo

[LeoAnderson]

non, tout à chaud !

ALTER TABLE MODIFY BLOB pour la conversion
suivi de DBMS_REDEFINITION pour partitionner

[orafrance]

DBMS_REDEFINITION pour partitionner après coup t'es sûr de toi ?

[LeoAnderson]

bien sûr !

et à chaud Monsieur, s'il vous plait !

[edit]par contre, faut être en 10g, et comme la version n'était pas indiquée, j'avais compris 11g par défaut mais la phrase "anticipé la future migration vers oracle 10g" me sème le doute....

par contre, les long et long raw existent toujours, mais c'est vraiment la plaie ces types... il faut les modifier, c'est sûr ! [/edit]

[orafrance]

Ha OK, c'est pour ça que ça me surprenait, j'en suis resté au "pas possible de partitionner une table après coup" de la 9i

Merci pour la précision

Envoyé par LeoAnderson

mais c'est vraiment la plaie ces types...

c'est rien de le dire

[wapette21]

Oui excuser moi je suis actuellement en 9i.

Pour ce qui est des long_raw quoi qu'il arrive je veux m'en séparer.

[orafrance]

donc :
CREATE TABLE ... AS INSERT ... SELECT avec TO_LOB

[wapette21]

Quellequ'un peut me dire le temps que cela prend en gros ?

sur du vecu - ma table contient plus de 2Millions de ligne.

Merci a vous tous.

[LeoAnderson]

Le MODIFY existe me semble-t-il en 9i...

de toute façon, si vous voulez passer en 10g, upgradez la base (par la procédure d'upgrade et non le dbua) et ensuite faites les MODIFY et DBMS_REDEFINITION

[orafrance]

encore une fois : non ! Ca dépend du matériel, du paramétrage, du volume de chaque ligne, du partitionnement, etc... fait un test

[LeoAnderson]

Envoyé par orafrance

encore une fois : non ! Ca dépend du matériel, du paramétrage, du volume de chaque ligne, du partitionnement, etc... fait un test

je suppose que tu répondais à wapette21 et non à moi ?

[orafrance]

bien sûr

quelle idée de repondre en même temps que moi aussi

[orafrance]

Envoyé par LeoAnderson

Le MODIFY existe me semble-t-il en 9i...

de toute façon, si vous voulez passer en 10g, upgradez la base (par la procédure d'upgrade et non le dbua) et ensuite faites les MODIFY et DBMS_REDEFINITION

en effet, autant le faire après coup

[wapette21]

merci pour vos réponse, mon appli ne va pas migrer tout suite en 10g.

encore une fois : non ! Ca dépend du matériel, du paramétrage, du volume de chaque ligne, du partitionnement, etc... fait un test

Mais question ne sont pas que pour Toi

enfin merci a vous tous et toi aussi orafrance

a bientot.

Yo

Ps je vais faire des tests en PP bien surs.

[orafrance]

Envoyé par wapette21

Mais question ne sont pas que pour Toi

Faut aller sur www.lavoyance-c-bien.fr pour avoir une réponse... ici c'est un forum sérieux