Достаточно давно вынес одну таблицу (с большими BLOB-ами) и всеми индексами в отдельное ТП
До этого все это лежало в другом ТП и занимало около 200гиг
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.
create tablespace l_dblob
blocksize 16k
extent management local uniform size 1M
segment space management auto
datafile
'/u/app/oracle/oradata/xxxx/l_dblob01.dbf' size 30720m reuse,
'/u/app/oracle/oradata/xxxx/l_dblob02.dbf' size 30720m reuse,
'/u/app/oracle/oradata/xxxx/l_dblob03.dbf' size 30720m reuse,
'/u/app/oracle/oradata/xxxx/l_dblob04.dbf' size 30720m reuse,
'/u/app/oracle/oradata/xxxx/l_dblob05.dbf' size 30720m reuse,
'/u/app/oracle/oradata/xxxx/l_dblob06.dbf' size 30720m reuse,
'/u/app/oracle/oradata/xxxx/l_dblob07.dbf' size 30720m reuse,
'/u/app/oracle/oradata/xxxx/l_dblob08.dbf' size 30720m reuse
/
create table dblob_new tablespace l_dblob
lob(val) store as securefile(tablespace l_dblob)
as select * from dblob where 1=0
/
set serveroutput on
declare n_errs number := 0;
begin
dbms_redefinition.start_redef_table(user, 'DBLOB', 'DBLOB_NEW');
dbms_redefinition.copy_table_dependents(user, 'DBLOB', 'DBLOB_NEW', num_errors=>n_errs);
dbms_output.put_line('copy_table_dependents: num_errors='||n_errs);
end;
/
exec dbms_redefinition.finish_redef_table(user, 'DBLOB', 'DBLOB_NEW')
alter index pk_dblob_id rebuild tablespace l_dblob
/
...
И заметил, что в одном датафайле (как оказалось, тот, в котором лежат заголовки всех сегментов этого ТП) место не распределяется
Т.е. DBMS_REDEFINITION разложил по файликам более-менее ровно, но после этого
распределяет автоматом только в другие датафайлы, если в них есть место (после первоначального разбиения уже добавилось 3 новых файла)
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.
SQL> column name format a30
SQL> with f as (select file_id, substr(file_name, instr(file_name, '/', -1)+1) name, blocks
2 from dba_data_files where tablespace_name='L_DBLOB'
3 ), ext as (select /*+ rule */ file_id, sum(blocks) blocks
4 from dba_extents where file_id in (select file_id from f)
5 group by file_id
6 ), fsp as (select /*+ rule */ file_id, sum(blocks) blocks
7 from dba_free_space where file_id in (select file_id from f)
8 group by file_id
9 )
10 select f.file_id, f.name, f.blocks, nvl(ext.blocks, 0) used, nvl(fsp.blocks, 0) free
11 from f, ext, fsp
12 where ext.file_id(+)=f.file_id and fsp.file_id(+)=f.file_id
13 order by f.name
14 /
FILE_ID NAME BLOCKS USED FREE
---------- ------------------------------ ---------- ---------- ----------
86 l_dblob01.dbf 1966080 1966016 0
87 l_dblob02.dbf 1966080 1966016 0
88 l_dblob03.dbf 1966080 1569984 396032
89 l_dblob04.dbf 1966080 1966016 0
90 l_dblob05.dbf 1966080 1966016 0
91 l_dblob06.dbf 1966080 1966016 0
92 l_dblob07.dbf 1966080 1966016 0
93 l_dblob08.dbf 1966080 1966016 0
14 l_dblob09.dbf 1966080 1966016 0
82 l_dblob10.dbf 1966080 1966016 0
95 l_dblob11.dbf 1441792 1379072 62656
11 rows selected.
...
-- через некоторое время
...
FILE_ID NAME BLOCKS USED FREE
---------- ------------------------------ ---------- ---------- ----------
...
88 l_dblob03.dbf 1966080 1569984 396032
...
95 l_dblob11.dbf 1441792 1379968 61760
11 rows selected.
И, соответственно, по сегментам
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.
SQL> column segment_name format a30
SQL> select de.segment_name, de.segment_type, min(ds.header_file) header_file,
2 de.file_id, nvl(sum(de.blocks), 0) blocks
3 from dba_segments ds, dba_extents de
4 where de.owner=ds.owner and de.segment_name=ds.segment_name and de.segment_type=ds.segment_type
5 and file_id in (88, 95)
6 group by de.segment_name, de.segment_type, de.file_id
7 order by 4, 1, 2
8 /
SEGMENT_NAME SEGMENT_TYPE HEADER_FILE FILE_ID BLOCKS
------------------------------ ------------------ ----------- ---------- ----------
PK_DBLOB_ID INDEX 88 88 704
SYS_IL0000816255C00003$$ LOBINDEX 88 88 64
SYS_LOB0000816255C00003$$ LOBSEGMENT 88 88 1565120
DBLOB TABLE 88 88 1984
IDX_DBLOB_0 INDEX 88 88 832
IDX_DBLOB_10 INDEX 88 88 448
IDX_DBLOB_12 INDEX 88 88 64
IDX_DBLOB_4 INDEX 88 88 768
SYS_LOB0000816255C00003$$ LOBSEGMENT 88 95 1378752
DBLOB TABLE 88 95 192
IDX_DBLOB_0 INDEX 88 95 64
IDX_DBLOB_4 INDEX 88 95 64
12 rows selected.
...
-- через время
...
SEGMENT_NAME SEGMENT_TYPE HEADER_FILE FILE_ID BLOCKS
------------------------------ ------------------ ----------- ---------- ----------
...
SYS_LOB0000816255C00003$$ LOBSEGMENT 88 88 1565120
...
SYS_LOB0000816255C00003$$ LOBSEGMENT 88 95 1379712
...
12 rows selected.
Причем, с помощью ALLOCATE EXTENT (или когда нет места в других файлах) все размещяется в файлике 88 безо всякой ругани.
И безо всяких пропусков
1.
2.
3.
4.
5.
6.
7.
8.
9.
SQL> select * from (
2 select block_id, blocks, lead(block_id, 1, -1) over (order by block_id) next_block
3 from dba_extents
4 where file_id=88
5 ) where block_id+blocks != next_block;
BLOCK_ID BLOCKS NEXT_BLOCK
---------- ---------- ----------
1569984 64 -1
Оно как бы пофиг, но не очень красиво дырку в середине оставлять
Да и интересно, что именно может мешать. Вот только как сформулировать запрос тому же металинку не соображу
Может кто уже сталкивался с таким? Или хотя бы есть мысли, что посмотреть?
версия
1.
2.
3.
4.
5.
6.
7.
8.
9.
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Solaris: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
