1620

Приложение А

18 (1, l raw) ;

20 dbms output.put line(created long with length =

21 length(l tmp));

22 end;

23 /

created long with length = 32003

PL/SQL procedure successfully completed.

Пример множественного однократного преобразования типа

Итак, имеется две таблицы с одной строкой и столбцом типа LONG или LONG AW. Преобразование типа данных из LONG в CLOB легко выполнить с помощью следующего оператора CREATE TABLE AS SELECT:

ops$tkyte@DEV816> create table clob table

2 as

3 select id, to lob(data) data

4 from long table;

Table created.

Кроме того, мы могли создать таблицы ранее и использовать для наполнения ее данными разновидность оператора INSERT INTO:

ops$tkyte@DEV816> insert into clob table

2 select id, to lob(data)

3 from long table;

1 created.

Следующий пример показывает, что функция TO LOB не работает в PL/SQL-блоке, как и следовало ожидать:

ops$tkyte@DEV816> begin

2 insert into clob table

3 select id, to lob(data)

4 from long table;

5 end;

begin *

ERROR at line 1:

ORA-06550: line 3, column 16:

PLS-00201: identifier TO LOB must be declared ORA-06550: line 2, column 5:

PL/SQL: SQL Statement ignored

Это ограничение легко обойти с помощью динамического SQL (придется вгполнять оператор INSERT динамически, а не статически, как в примере выше). Теперь, разобравшись, как преобразовывать данные типа LONG или LONG RAW в тип CLOB или BLOB, рассмотрим производительность такого преобразования. Обычно таблицы со

Пакет DBMS LOB

1621

столбцами типа LONG и LONG RAW - большого размера. Они большие по определению, поскольку используются для хранения очень больших объектов. Во многих случаях их размер достигает многих гигабайт. Вопрос в том, можно ли выполнить множественное преобразование за допустимое время? Рекомендую использовать следующие возможности:

невосстановимые действия, такие как непосредственная вставка и опция NOLOGGING;

распараллеливание операторов ЯМД (в частности, параллельные вставки);

параллельные запросы.

Ниже представлен пример использования этих возможностей. У меня есть большая таблица IMAGE, содержащая многие сотни загруженных из Web файлов. Таблица содержит столбцы name (название документа), MIME TYPE (например, application/MS-Word), IMG SIZE (размер документа в байтах) и, наконец, сам документ в столбце типа and LONG RAW. Преобразуем эту таблицу так, чтобы документ хранился в столбце типа BLOB. Можно начать с создания новой таблицы:

scott@DEV816> GREATE TABLE SGOTT . T

2 ( N VARGHAR2(255) ,

3 MIME TYPE VARGHAR2(2 55),

4 IMG SIZE NUMBER,

5 IMAGE BLOB)

6 PGTFREE 0 PGTUSED 40

7 INITRANS 1

8 MARANS 255

9 NOLOGGING

10 TABLESPAGE USERS

11 LOB ( IMAGE ) STORE AS

12 (TABLESPAGE USERS

13 DISABLE STORAGE IN ROW GHUNK 32768

14 PGTVERSION 10

15 NOGAGHE

16 NOLOGGING

17 ) ;

Table created.

Обратите внимание, что таблица и большой объект создаются с опцией NOLOGGING - это важно. Можно не создавать их так сразу, а применить оператор ALTER. Теперь, чтобы преобразовать данные из существующей таблицы IMAGE, выполним следующее:

scott@DEV816> ALT session ABIE PARALLEL DMI;

Session altered.

scott@DEV816> INSERT /*+ APP PARALLEL(t,5) */ INTO t

2 SECT /*+ PARALLEL(long raw,5) */

3 name, mimetype, imgsize, to lob(image)

4 IRCM longraw;

В результате выполняется непосредственная параллельная вставка в объекты типа BLOB без журнализации. Для сравнения я выполнил INSERT INTO c включенной и

1622

Приложение А

отключенной журнализацией и получил следующие результаты (на подмножестве преобразуемых строк):

scott@DEV816> create table t

2 as

3 select name, mime type, img size, to lob(image) image

4 from image where l=0; Таblе created.

scott@DEV816> set autotrace on scott@DEV816> insert into t

2 select name, mime type, img size, to lob(image) image

3 from image; 99 rows created.

Execution Plan

0 INSERT STATEMENT Optimizer=CHOOSE

1 0 TABLE ACCESS (FULL) OF IMAGE

Statistics

1242 recursive calls 36057 db block gets 12843 consistent gets 7870 physical reads 34393500 redo size

1006 bytes sent via SQL*Net to client 861 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 99 rows processed

Обратите внимание, что в результате б1ло сгенерировано 34 Мбайт данных повторного выполнения (если суммировать размеры 99 изображений, получится 32 Мбайт данных). Если таблица T, как б1ло показано ранее, создается с опцией NOLOGGING и используется непосредственная вставка, получим:

scott@DEV816> INSERT /*+ APPEND */ INTO t

2 SELECT name, mime type, img size, to lob(image)

3 FROM image;

99 rows created. Execution Plan

0 INSERT STATEMENT Optimizer=CHOOSE

1 0 TABLE ACCESS (FULL) OF IMAGE Statistics

1242 recursive calls

36474 db block gets 13079 consistent gets 6487 physical reads