Will a Bigger Next Extent Results In Smaller Fragmentation [message #647605] |
Wed, 03 February 2016 21:42 ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](//www.gravatar.com/avatar/82920145e40e0c65c671e4d0b8212ab7?s=64&d=mm&r=g) |
juniordbanewbie
Messages: 250 Registered: April 2014
|
Senior Member |
|
|
Dear all,
smaller_next
CREATE TABLESPACE smaller_next DATAFILE '/u02/app/oracle2/oradata/ORCL/smaller_next_01.dbf' SIZE 1M AUTOEXTEND ON NEXT 1M extent management local segment space management auto;
bigger_next
CREATE TABLESPACE bigger_next DATAFILE '/u02/app/oracle2/oradata/ORCL/bigger_next_01.dbf' SIZE 1M AUTOEXTEND ON NEXT 10M extent management local segment space management auto;
with the above create tablespace sql, which tablespace will result in a larger fragmentation?
I did the following test:
create 4 tables namely
CREATE TABLE t1_smaller_next (
id NUMBER,
description VARCHAR2(1000),
CONSTRAINT t1_smaller_next_pk PRIMARY KEY (id)
)tablespace smaller_next;
CREATE TABLE t2_smaller_next (
id NUMBER,
description VARCHAR2(1000),
CONSTRAINT t2_smaller_next_pk PRIMARY KEY (id)
)tablespace smaller_next;
CREATE TABLE t1_bigger_next (
id NUMBER,
description VARCHAR2(1000),
CONSTRAINT t1_bigger_next_pk PRIMARY KEY (id)
)tablespace bigger_next;
CREATE TABLE t2_bigger_next (
id NUMBER,
description VARCHAR2(1000),
CONSTRAINT t2_bigger_next_pk PRIMARY KEY (id)
)tablespace bigger_next;
inserting data
INSERT /*+append*/ INTO t1_smaller_next
SELECT rownum, RPAD('x', 1000, 'x')
FROM dual
CONNECT BY level <= 10000;
COMMIT;
INSERT /*+append*/ INTO t2_smaller_next
SELECT rownum, RPAD('x', 1000, 'x')
FROM dual
CONNECT BY level <= 10000;
COMMIT;
INSERT /*+append*/ INTO t1_bigger_next
SELECT rownum, RPAD('x', 1000, 'x')
FROM dual
CONNECT BY level <= 10000;
COMMIT;
INSERT /*+append*/ INTO t2_bigger_next
SELECT rownum, RPAD('x', 1000, 'x')
FROM dual
CONNECT BY level <= 10000;
COMMIT;
before and after truncating t1_smaller_next and t1_bigger_next, run the following script
SET SERVEROUTPUT ON SIZE 1000000
SET FEEDBACK OFF
SET TRIMOUT ON
SET VERIFY OFF
DECLARE
l_tablespace_name VARCHAR2(30) := UPPER('&1');
l_file_id VARCHAR2(30) := UPPER('&2');
CURSOR c_extents IS
SELECT owner,
segment_name,
file_id,
block_id AS start_block,
block_id + blocks - 1 AS end_block
FROM dba_extents
WHERE tablespace_name = l_tablespace_name
AND file_id = DECODE(l_file_id, 'ALL', file_id, TO_NUMBER(l_file_id))
ORDER BY file_id, block_id;
l_block_size NUMBER := 0;
l_last_file_id NUMBER := 0;
l_last_block_id NUMBER := 0;
l_gaps_only BOOLEAN := TRUE;
l_total_blocks NUMBER := 0;
BEGIN
SELECT block_size
INTO l_block_size
FROM dba_tablespaces
WHERE tablespace_name = l_tablespace_name;
DBMS_OUTPUT.PUT_LINE('Tablespace Block Size (bytes): ' || l_block_size);
FOR cur_rec IN c_extents LOOP
IF cur_rec.file_id != l_last_file_id THEN
l_last_file_id := cur_rec.file_id;
l_last_block_id := cur_rec.start_block - 1;
END IF;
IF cur_rec.start_block > l_last_block_id + 1 THEN
DBMS_OUTPUT.PUT_LINE('*** GAP *** (' || l_last_block_id || ' -> ' || cur_rec.start_block || ')' ||
' FileID=' || cur_rec.file_id ||
' Blocks=' || (cur_rec.start_block-l_last_block_id-1) ||
' Size(MB)=' || ROUND(((cur_rec.start_block-l_last_block_id-1) * l_block_size)/1024/1024,2)
);
l_total_blocks := l_total_blocks + cur_rec.start_block - l_last_block_id-1;
END IF;
l_last_block_id := cur_rec.end_block;
IF NOT l_gaps_only THEN
DBMS_OUTPUT.PUT_LINE(RPAD(cur_rec.owner || '.' || cur_rec.segment_name, 40, ' ') ||
' (' || cur_rec.start_block || ' -> ' || cur_rec.end_block || ')');
END IF;
END LOOP;
DBMS_OUTPUT.PUT_LINE('Total Gap Blocks: ' || l_total_blocks);
DBMS_OUTPUT.PUT_LINE('Total Gap Space (MB): ' || ROUND((l_total_blocks * l_block_size)/1024/1024,2));
END;
/
PROMPT
SET FEEDBACK ON
SET ECHO OFF
SPOOL OFF
here's my outcome before truncating table t1_smaller_next
Enter value for 1: smaller_next
Enter value for 2: 10
Tablespace Block Size (bytes): 8192
*** GAP *** (1719 -> 1792) FileID=10 Blocks=72 Size(MB)=.56
Total Gap Blocks: 72
Total Gap Space (MB): .56
SYS@ORCL>
SYS@ORCL>PROMPT
after truncating t1_smaller_next
Enter value for 1: smaller_next
Enter value for 2: 10
Tablespace Block Size (bytes): 8192
*** GAP *** (39 -> 176) FileID=10 Blocks=136 Size(MB)=1.06
*** GAP *** (255 -> 1664) FileID=10 Blocks=1408 Size(MB)=11
*** GAP *** (1719 -> 1792) FileID=10 Blocks=72 Size(MB)=.56
Total Gap Blocks: 1616
Total Gap Space (MB): 12.63
SYS@ORCL>
SYS@ORCL>PROMPT
before truncating t1_bigger_next
Enter value for 1: bigger_next
Enter value for 2: 11
Tablespace Block Size (bytes): 8192
*** GAP *** (1719 -> 1792) FileID=11 Blocks=72 Size(MB)=.56
Total Gap Blocks: 72
Total Gap Space (MB): .56
SYS@ORCL>
after truncating t1_bigger_next
Enter value for 1: bigger_next
Enter value for 2: 11
Tablespace Block Size (bytes): 8192
*** GAP *** (39 -> 176) FileID=11 Blocks=136 Size(MB)=1.06
*** GAP *** (255 -> 1664) FileID=11 Blocks=1408 Size(MB)=11
*** GAP *** (1719 -> 1792) FileID=11 Blocks=72 Size(MB)=.56
Total Gap Blocks: 1616
Total Gap Space (MB): 12.63
If u look at the after results, it seems that there's no difference between a tablespace with lower next extent and one with a higher next extent after truncating the table.
maybe I was testing the wrong way, can someone enlighten me on how to verify the following fact:
Will a Bigger Next Extent Results In Smaller Fragmentation
Or if the fact is not true at all.
many thanks in advance!
|
|
|
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647614 is a reply to message #647611] |
Thu, 04 February 2016 02:50 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](//www.gravatar.com/avatar/82920145e40e0c65c671e4d0b8212ab7?s=64&d=mm&r=g) |
juniordbanewbie
Messages: 250 Registered: April 2014
|
Senior Member |
|
|
from https://docs.oracle.com/cd/E11882_01/server.112/e40540/logical.htm#CNCPT3000
I realize that by setting the next extents to a small value, it won't lead to disk fragmentation.
but since segments can be made up of noncontinuous or continuous extents, it may be possible that having a small next extend could lead to segment fragmentation.
but based on my testing, it definitely does not conclude that having a small next extend can lead to segment fragmentation.
SYS@ORCL>SELECT file_id, bytes/1024/1024 size_in_mb, maxbytes/1024/1024 maxbytes_in_mb, increment_by FROM dba_data_files WHERE file_name='/u02/app/oracle2/oradata/ORCL/smaller_next_01.dbf';
FILE_ID SIZE_IN_MB MAXBYTES_IN_MB INCREMENT_BY
---------- ---------- -------------- ------------
10 26 32767.9844 128
SELECT file_id, bytes/1024/1024 size_in_mb, maxbytes/1024/1024 maxbytes_in_mb, increment_by FROM dba_data_files WHERE file_name='/u02/app/oracle2/oradata/ORCL/bigger_next_01.dbf';
FILE_ID SIZE_IN_MB MAXBYTES_IN_MB INCREMENT_BY
---------- ---------- -------------- ------------
11 31 32767.9844 1280
for the bigger_next tablespace which has a bigger next extend of 100M, it does not have less segment fragmentation compare to smaller_next tablespace.
Enter value for 1: bigger_next
Enter value for 2: 11
Tablespace Block Size (bytes): 8192
*** GAP *** (39 -> 176) FileID=11 Blocks=136 Size(MB)=1.06
*** GAP *** (255 -> 1664) FileID=11 Blocks=1408 Size(MB)=11
*** GAP *** (1719 -> 1792) FileID=11 Blocks=72 Size(MB)=.56
Total Gap Blocks: 1616
Total Gap Space (MB): 12.63
Enter value for 1: smaller_next
Enter value for 2: 10
Tablespace Block Size (bytes): 8192
*** GAP *** (39 -> 176) FileID=10 Blocks=136 Size(MB)=1.06
*** GAP *** (255 -> 1664) FileID=10 Blocks=1408 Size(MB)=11
*** GAP *** (1719 -> 1792) FileID=10 Blocks=72 Size(MB)=.56
Total Gap Blocks: 1616
Total Gap Space (MB): 12.63
I mean if bigger_next tablespace will have fewer fragmentation the result would be like the following:
Enter value for 1: bigger_next
Enter value for 2: 11
Tablespace Block Size (bytes): 8192
*** GAP *** (169-> 176) FileID=11 Blocks=1 Size(MB)=0.0625
*** GAP *** (1667 -> 1664) FileID=11 Blocks=1408 Size(MB)=0.0625
*** GAP *** (1665 -> 1792) FileID=11 Blocks=72 Size(MB)=1
Total Gap Blocks: 1616
Total Gap Space (MB): 12.63
again that's only in theory
or am i testing the wrong way?
again I have to ask user do they care about segment fragmentation now that it is clear that having a smaller extent don't lead to disk fragmentation.
|
|
|
|
|
|
|
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647674 is a reply to message #647672] |
Fri, 05 February 2016 00:42 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](//www.gravatar.com/avatar/82920145e40e0c65c671e4d0b8212ab7?s=64&d=mm&r=g) |
juniordbanewbie
Messages: 250 Registered: April 2014
|
Senior Member |
|
|
DATA1--------|FREE1-----|DATA2-------|FREE2-------|DATA3----------|FREE3---------------------------------|HWM
=>FREE1 and FREE2, Free3 is are free space
but FREE1 and FREE2 are also fragmented space
FREE and fragmented SPACE is a problem when it is too small for new data to be inserted
from https://docs.oracle.com/cd/E11882_01/server.112/e25494/schema.htm#ADMIN01401
Quote:
Over time, updates and deletes on objects within a tablespace can create pockets of empty space that individually are not large enough to be reused for new data. This type of empty space is referred to as fragmented free space.
Objects with fragmented free space can result in much wasted space, and can impact database performance.
However I do not really agree with the portion of statement "can impact database performance".
Maybe someone could enlighten me how does fragmented space could impact database performance. As far I know, if I scan data across two noncontinuous extents in the same file, it won't degrade performance unless the two range are in different file.
many thanks
[Updated on: Fri, 05 February 2016 01:03] Report message to a moderator
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647678 is a reply to message #647674] |
Fri, 05 February 2016 01:17 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](/forum/images/custom_avatars/102589.gif) |
Michel Cadot
Messages: 68733 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
juniordbanewbie wrote on Fri, 05 February 2016 01:05Are you saying that you store your data directly on internal disks and do not use SAN/NAS?
=> I don't know. just being shot an email from my department head on customer complaining that when creating tablespace
Your question is completely meaningless if you do not use direct disk access.
Quote:Maybe someone could enlighten me how does fragmented space could impact database performance.
See my previous sentence.
Quote:As far I know, if I scan data across two noncontinuous extents in the same file, it won't degrade performance unless the two range are in different file.
Who say that extents are made of continuous blocks in a file?
Who say that accessing different extents in different files are slower that accessing different extents or even a single extent in a single file?
The main and PRIME question you have to ask in on what you data are stored.
Without this, all you do is useless and just a waste of time.
[Updated on: Fri, 05 February 2016 01:19] Report message to a moderator
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647679 is a reply to message #647674] |
Fri, 05 February 2016 01:39 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
John Watson
Messages: 8964 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
I hesitated before contributing to this topic. But it is early in the morning, and I don't want to start work yet. So I'll try.
"Fragmentation" is generally a meaningless term in the Oracle environment. You must define what you mean by it. You appear to be using it to refer to a segment consisting of multiple extents, where the extents are not contiguous (I think you mean "contiguous" rather than "continuous") in terms of the Oracle block number.
This may result in two issues: one genuine, the other false.
THe genuine problem is that if the free extents between the used extents are different sizes, it may not be possible to re-use the space. To avoid this, make sure that all extents on the tablespace are the same size. Do NOT use different values for auto extension. Better still, create the tablespace with uniform extent size.
The false problem is that distributing a segment across multiple non-contiguous extents will impact adversely on performance. This is rarely true, for at least two reasons. Firstly, the fact that the Oracle blocks are consecutively numbered does not mean that they are physically adjacent. Oracle has no idea how the inode has distributed the file across the disc. One Oracle block may itself be distributed. Secondly, even if the blocks are physically adjacent, this has no benefit for any IO based on single block reads and writes. Singe block read/write is probably the majority of your IO.
You need to tell your client to stop worrying about things that have no meaning in the Oracle context.
|
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647681 is a reply to message #647680] |
Fri, 05 February 2016 02:08 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](/forum/images/custom_avatars/102589.gif) |
Michel Cadot
Messages: 68733 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
Quote:=>but then why must it be direct disk access?
It must NOT, this is why all this topic is a waste of energy at 99.999%.
Quote:Who say that extents are made of continuous blocks in a file?
They are contiguous from Oracle point of view NOT storage one.
Storage lies to those who use it.
And this does not matter.
Quote:=>since single extents can never span data files, then an extent are made of contiguous data blocks in the same data file, right?
Again this depends on the storage and most of the time, wrong.
see John's answer.
[Updated on: Fri, 05 February 2016 02:09] Report message to a moderator
|
|
|
|
|
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647730 is a reply to message #647729] |
Sat, 06 February 2016 09:33 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](//www.gravatar.com/avatar/82920145e40e0c65c671e4d0b8212ab7?s=64&d=mm&r=g) |
juniordbanewbie
Messages: 250 Registered: April 2014
|
Senior Member |
|
|
SYS@ORCL>DECLARE
2 l_tablespace_name VARCHAR2(30) := UPPER('&1');
3 l_file_id VARCHAR2(30) := UPPER('&2');
4 l_segment_name VARCHAR2(30) := UPPER('&3');
5
6 CURSOR c_extents IS
7 SELECT owner,
8 segment_name,
9 file_id,
10 block_id AS start_block,
11 block_id + blocks - 1 AS end_block
12 FROM dba_extents
13 WHERE tablespace_name = l_tablespace_name
14 AND file_id = DECODE(l_file_id, 'ALL', file_id, TO_NUMBER(l_file_id))
15 AND segment_name = l_segment_name
16 ORDER BY file_id, block_id;
17
18 l_block_size NUMBER := 0;
19 l_last_file_id NUMBER := 0;
20 l_last_block_id NUMBER := 0;
21 l_gaps_only BOOLEAN := TRUE;
22 l_total_blocks NUMBER := 0;
23 BEGIN
24 SELECT block_size
25 INTO l_block_size
26 FROM dba_tablespaces
27 WHERE tablespace_name = l_tablespace_name;
28
29 DBMS_OUTPUT.PUT_LINE('Tablespace Block Size (bytes): ' || l_block_size);
30 FOR cur_rec IN c_extents LOOP
31 IF cur_rec.file_id != l_last_file_id THEN
32 l_last_file_id := cur_rec.file_id;
33 l_last_block_id := cur_rec.start_block - 1;
34 END IF;
35
36 IF cur_rec.start_block > l_last_block_id + 1 THEN
37 DBMS_OUTPUT.PUT_LINE('*** GAP *** (' || l_last_block_id || ' -> ' || cur_rec.start_block || ')' ||
38 ' FileID=' || cur_rec.file_id ||
39 ' Blocks=' || (cur_rec.start_block-l_last_block_id-1) ||
40 ' Size(MB)=' || ROUND(((cur_rec.start_block-l_last_block_id-1) * l_block_size)/1024/1024,2)
41 );
42 l_total_blocks := l_total_blocks + cur_rec.start_block - l_last_block_id-1;
43 END IF;
44 l_last_block_id := cur_rec.end_block;
45 IF NOT l_gaps_only THEN
46 DBMS_OUTPUT.PUT_LINE(RPAD(cur_rec.owner || '.' || cur_rec.segment_name, 40, ' ') ||
47 ' (' || cur_rec.start_block || ' -> ' || cur_rec.end_block || ')');
48 END IF;
49 END LOOP;
50 DBMS_OUTPUT.PUT_LINE('Total Gap Blocks: ' || l_total_blocks);
51 DBMS_OUTPUT.PUT_LINE('Total Gap Space (MB): ' || ROUND((l_total_blocks * l_block_size)/1024/1024,2));
52 END;
53 /
Enter value for 1: smaller_next
Enter value for 2: 10
Enter value for 3: t1_smaller_next
Tablespace Block Size (bytes): 8192
*** GAP *** (15 -> 24) FileID=10 Blocks=8 Size(MB)=.06
*** GAP *** (143 -> 256) FileID=10 Blocks=112 Size(MB)=.88
Total Gap Blocks: 120
Total Gap Space (MB): .94
SYS@ORCL>
Maybe I was wrong, but again nobody knows every thing in this world. But I believe John have given me the best answer although I only realize he has already reply to me earlier.
thanks
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647731 is a reply to message #647728] |
Sat, 06 February 2016 09:37 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
John Watson
Messages: 8964 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
If you really want to fix this problem (though whether it IS a problem is debatable) you need to move all the objects into a tablespace created with uniform extent size. When you tell your customer the number of hours you will bill him to do this, he may decide that the problem is not so important.
|
|
|
|
|
|
|
Re: Will a Bigger Next Extent Results In Smaller Fragmentation [message #647737 is a reply to message #647730] |
Sat, 06 February 2016 10:37 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) |
![](/forum/images/custom_avatars/102589.gif) |
Michel Cadot
Messages: 68733 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
Quote:But I believe John have given me the best answer although I only realize he has already reply to me earlier.
Of course, in our answer we assume you have read all previous answers, above all when we say:
Michel Cadot wrote on Fri, 05 February 2016 09:08...see John's answer.
|
|
|