{ "date": "2017-04-21T19:47:20", "slug": "securefiles-on-multi-datafiles-tablespaces", "link": "https://www.dbi-services.com/blog/securefiles-on-multi-datafiles-tablespaces/", "title": { "rendered": "SecureFiles on multi-datafiles tablespaces" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nWhen we have a tablespace with multiple datafiles, we are used to seeing the datafiles filled evenly, the extents being allocated in a round-robin fashion. In the old time, we used that to maximize performance, distributing the tables to all disks. Today, we use LVM striping, maximum Inter-Policy, ASM even distribution. And we may even use bigfile tablespaces, so that we don’t care about having multiple datafiles.
\n
\nBut recently, during test phase of migration, I came upon something like this:
\n\"SecureFile003\"

\n

To reproduce the case, I’ve created a tablespace with 8 datafiles:

\n
\nSQL> create tablespace MYTABS datafile\n  2  '/tmp/MYTABS01.dbf' size 1M autoextend on maxsize 100M,\n  3  '/tmp/MYTABS02.dbf' size 1M autoextend on maxsize 100M,\n  4  '/tmp/MYTABS03.dbf' size 1M autoextend on maxsize 100M,\n  5  '/tmp/MYTABS04.dbf' size 1M autoextend on maxsize 100M,\n  6  '/tmp/MYTABS05.dbf' size 1M autoextend on maxsize 100M,\n  7  '/tmp/MYTABS06.dbf' size 1M autoextend on maxsize 100M,\n  8  '/tmp/MYTABS07.dbf' size 1M autoextend on maxsize 100M,\n  9  '/tmp/MYTABS08.dbf' size 1M autoextend on maxsize 100M\n 10  /\n \nTablespace created.\n
\n

SecureFiles

\n

This was a 11g to 12c migration, with Data Pump, and a good occasion to convert all LOB to SecureFiles with the transform=lob_storage:securefile parameter. And this tablespace is the one where the LOB segments are stored. I reproduced it with:

\n
SQL> create table MYTABLE ( x clob ) tablespace USERS\n  2  LOB(x) store as securefile MYLOBSEG (tablespace MYTABS disable storage in row);\n \nTable created.\n
\n

Then I inserted about 80MB:

\n
SQL> insert into MYTABLE select lpad('x',100000) from xmltable('1 to 8000') ;\n8000 rows created.\n \nSQL> select file_id,file_name,blocks,user_blocks from dba_data_files where tablespace_name='MYTABS' order by file_id;\n \n   FILE_ID FILE_NAME                          BLOCKS USER_BLOCKS\n---------- ------------------------------ ---------- -----------\n        61 /tmp/MYTABS01.dbf                     128         120\n        62 /tmp/MYTABS02.dbf                     128         120\n        63 /tmp/MYTABS03.dbf                     128         120\n        64 /tmp/MYTABS04.dbf                    9344        9336\n        65 /tmp/MYTABS05.dbf                     128         120\n        66 /tmp/MYTABS06.dbf                     128         120\n        67 /tmp/MYTABS07.dbf                     128         120\n        68 /tmp/MYTABS08.dbf                     128         120\n \n8 rows selected.\n \nSQL> select file_id,segment_type,sum(blocks) from dba_extents where tablespace_name='MYTABS' group by file_id,segment_type order by file_id,segment_type;\n \n   FILE_ID SEGMENT_TYPE       SUM(BLOCKS)\n---------- ------------------ -----------\n        64 LOBSEGMENT                9216\n        65 LOBINDEX                     8\n        65 LOBSEGMENT                  24\n
\n

And I continued to load rows, and observed the datafiles filled to their maxsize one after the other, without numeric or alphabetical order.

\n
SQL> select file_id,file_name,blocks,user_blocks from dba_data_files where tablespace_name='MYTABS' order by file_id;\n \n   FILE_ID FILE_NAME                          BLOCKS USER_BLOCKS\n---------- ------------------------------ ---------- -----------\n        61 /tmp/MYTABS01.dbf                    8320        8312\n        62 /tmp/MYTABS02.dbf                   12416       12408\n        63 /tmp/MYTABS03.dbf                   12416       12408\n        64 /tmp/MYTABS04.dbf                   12416       12408\n        65 /tmp/MYTABS05.dbf                     128         120\n        66 /tmp/MYTABS06.dbf                     128         120\n        67 /tmp/MYTABS07.dbf                     128         120\n        68 /tmp/MYTABS08.dbf                     128         120\n \n8 rows selected.\n \nSQL> select file_id,segment_type,sum(blocks) from dba_extents where tablespace_name='MYTABS' group by file_id,segment_type order by file_id,segment_type;\n \n   FILE_ID SEGMENT_TYPE       SUM(BLOCKS)\n---------- ------------------ -----------\n        61 LOBSEGMENT                8192\n        62 LOBSEGMENT               12288\n        63 LOBSEGMENT               12288\n        64 LOBSEGMENT               12288\n        65 LOBINDEX                     8\n        65 LOBSEGMENT                  24
\n

Here are some screenshots during this load

\n

\"SecureFile001\"

\n

\"SecureFile002\"

\n

\"SecureFile003\"

\n

BasicFiles

\n

This occurs only with SecureFiles. With the same load into LOB stored as BasicFile I got the following distribution:
\n\"SecureFile004\"

\n

Note that the inserts to BasicFile were about two times slower than the same into SecureFiles.

\n

So what?

\n

I don’t see any bad consequences about that, and this may even be an improvement when concurrent sessions are loading the LOBs. When the datafile picked-up looks random, a guess is that it depends on a process ID to try to distribute the concurrent load. And if you want to distribute data over multiple disks, then you should do it at a lower level. However, it is 30 years behavior that changes and it’s better to be aware of it: datafiles may reach their maxsize even when the tablespace is not full. I order to be sure that it is the expected behavior, I opened an SR with easy to reproduce testcase. Status is ‘review update’ for 9 days (SR 3-14677784041) and I’ll update this post is I get an answer.

\n", "protected": false } }