Discussion :

[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 :

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

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 :

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

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 :

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

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