The impact of extent contiguity on performance

The Contiguousness of Extents Administration Tips

Do Extents need to be next to each other in the Tablespace?
A lot of people often ask whether the fact that a segment’s extents are scattered
throughout a tablespace and interspersed with the extents from other segments makes a
difference to the performance of queries and DML on that segment.

For example, if Tables A, B and C have their extents arranged within a tablespace like this:

AAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCC

…we would say that Table A’s extents were contiguous one with another. Likewise, Table
B’s extents are contiguous, and so are Table C’s.

On the other hand, it is rather more likely in a production system that you.d see a random
arrangements of extents, like this:

ABCBCBCAABCBACBCBCBCAABCBAABCBCBCABCBBABCBCBCAABCBACBAABCBCBCABC

…and so on. Arranged like this, we say that Table A’s (and B’s and C’s) extents are
discontiguous. The question is therefore whether the discontiguousness of a table’s
extents matter for the speed with which Oracle can perform selects, inserts, updates and
deletes on that segment.

At the end of this paper is a simple test you can run to demonstrate the truth of this for
yourself. It’s a script which will create a procedure called ‘CONTEST’. That procedure
creates a number of tables (you decide how many when you call the procedure) with their
extents beautifully contiguous to each other… and then repeats the process, but this time
making sure that the extents are totally discontiguous. It loads each table with around
half a million rows, and then monitors the time it takes to select and delete all those
records.

The nice thing about the procedure is that you can run it easily several times –making it
create the tables in a variety of different tablespaces. Given this ability, it is now trivial
to compare the performance for tables with large extents versus ones with lots of small
extents –you just make sure you create tablespaces that allocate differently-sized extents
to segments housed within them. It’s also easy to compare dictionary-managed
tablespaces with locally managed tablespaces: just run the procedure first on a dictionary-
managed tablespace, and then repeat the run specifying a locally managed one.

For the test to be fair, it’s important that you run it against a freshly-created tablespace.
If you use an existing one, there’s no guarantee that what the procedure seeks to create as
contiguous actually will be contiguous.

Copyright © Howard Rogers 2002 3/11/2002 Page 1 of 8


It’s also important that the account used to run the tests should be freshly-created,
owning no other objects in the database. This User needs execute rights on the
dbms_utility package, and an unlimited quota on the tablespace you’ve created to run the
test against. So, you might do the following preparatory work:

create tablespace CONTEST1 datafile 'd:somewherefilename1.dbf'
size 500m autoextend on next 500m minimum extent 64k default storage (maxextents
2000 initial 64k next 64k pctincrease 0) extent management dictionary;

Create user howard identified by password;
Grant create session, create procedure to howard;
Grant execute on dbms_utility to howard;
Grant select any table,create any table,delete any table,drop any table to howard;
Alter user howard quota unlimited on contest1;

Obviously, if you want to test the performance of locally managed tablespaces, that first
command would be replaced with something rather more like this:

create tablespace CONTEST1 datafile 'd:somewherefilename1.dbf' size 500m
autoextend on next 500m extent management local uniform size 64k;

Next you need to create the procedure in the schema of the user just created. If you save
the script as a text file, called “contig.txt”, you just do this:

SQL>@c:somewherecontig.txt

Incidentally, the script is downloadable in its own right from www.hjrdba.com/scripts/contig.sql

Once you’ve done that, you’re ready to execute the procedure. It accepts four
parameters: how many tables do you want to test with, the tablespace in which they
should be created (enclosed in quotation marks), the number of records you want to
populate them with, and the directory on the server itself where the test results should be
written to (again in quotation marks):

SQL> execute contest(5,’CONTEST1’,500000,’C:TEMP’)

That last parameter must match your init.ora’s UTL_FILE_DIR parameter exactly. If you
haven’t got it set in your init.ora, you will need to set it and re-start the Instance
afterwards. The results are output in a file called contest.txt. For good measure, the
test runs with the same settings three times.

If you then want to repeat the test on a differently-sized or differently-managed
tablespace, just create the new tablespace, and re-execute the procedure, specifying the
new tablespace name. The new results will replace the old ones, though –so you might
want to re-name the original contest.txt file first.

Obviously, the real fun with this procedure is testing it out for yourself, in your own
environment. But here are the results of a few runs I performed on a rather pathetic
Celeron 1GHz machine with all datafiles on a single hard disk:



RUN 1:
------------------------------------------------------ ------------------------------------------------------
760 CONTIGUOUS EXTENTS 12 CONTIGUOUS EXTENTS
------------------------------------------------------ ------------------------------------------------------
503994 records for Table CON1 selected in 2.39 seconds 503994 records for Table CON1 selected in 2.21 seconds
Average select time for all tables: 2.252 seconds. Average select time for all tables: 2.152 seconds.
504450 records for Table CON1 deleted in 49.42 seconds 504450 records for Table CON1 deleted in 44.64 seconds
Average delete time for all tables: 48.186 seconds. Average delete time for all tables: 53.848 seconds.
------------------------------------------------------ ------------------------------------------------------
760 DISCONTIGUOUS EXTENTS 12 DISCONTIGUOUS EXTENTS
------------------------------------------------------ ------------------------------------------------------

RUN 2:
------------------------------------------------------ ------------------------------------------------------
------------------------------------------------------ ------------------------------------------------------
------------------------------------------------------ ------------------------------------------------------
------------------------------------------------------ ------------------------------------------------------



RUN 3:
------------------------------------------------------ ------------------------------------------------------
------------------------------------------------------ ------------------------------------------------------
------------------------------------------------------ ------------------------------------------------------
------------------------------------------------------ ------------------------------------------------------

I’m no statistician, but given the degree of variation that is evident between runs, and
even between processing the same number of records for different tables within a run,
there’s no significant difference between contiguous and discontiguous, large or small
extents, whether selecting records or performing DML on them.

If you just average the averages, you end up with this result:

Contiguous small extents: 2.32 seconds to select, 47.28 seconds to delete
Discontiguous small extents: 2.90 seconds to select, 49.63 seconds to delete

Contiguous large extents: 2.22 seconds to select, 53.61 seconds to delete
Discontiguous large extents: 2.46 seconds to select, 49.89 seconds to delete

Slice it and dice it any way you like, but there just isn’t a pattern in these figures. Neither
the contiguity of extents (or lack thereof), nor the number of extents involved, makes any
significant difference to the speed with which deletes or selects are performed.

No doubt you could think of ways of improving this test: create 1000 segments, for
example, or process more rows. Be my guest: I’d love to see the results, because however
many segments you create, and however discontiguous you make them, you’ll be running
up against a fundamental physical fact: even the blocks within a single extent aren’t
actually contiguous on the hard disk.



Extents are logical entities. They don’t have any real physical existence: at the end of the
day, everything gets stored in operating system blocks on the hard disk anyway. It’s up to
the operating system to determine which operating system blocks to use when storing data
–and, with the best will in the world, its chances of giving you a contiguous set of blocks in
which to store your data are exceedingly slim.

All Oracle is doing is imposing a level of logical structuring on those O/S blocks, saying, in
effect, that “these 16 512-byte operating system blocks will be regarded by me as
comprising one logical entity, a single 8K Oracle block.” But however Oracle regards those
16 O/S blocks, the fact remains that they are independent physical entities .and they can
(and will) come from all over the physical disk platter. Now if even an Oracle block is not
contiguous on disk, how can you expect a single extent to be physically contiguous? And if
a single extent cannot be physically contiguous, then it is obvious that a multiplicity of
extents can’t be contiguous either. Therefore, the contiguity of extents is a mirage that
never actually happens at the physical hard disk level.

Never mind the final argument: the contiguity of extents is often touted as a performance
booster, because it means the disk head doesn’t have to move around so much between
reads. But in a multi-user system, how often are your disk heads going to be able to move
uninterruptedly from one O/S block to another before another User directs them to move
somewhere completely different? Never, is the short answer.

That’s why it is pointless spending a great deal of time and effort striving to achieve a
single large extent for a segment. It’s why the number of extents for a segment (in Locally
Managed Tablespace, at any rate) is of so little concern. And it’s also why you shouldn’t
worry about precisely where in a tablespace those extents end up.

Extent numbers can be a concern, of course, in Dictionary Managed Tablespace. See my
paper in response to the question “Is there a “right” number of extents for a segment” for
details, though the short story is that anything up to a few hundred extents is still going to
impose no noticeable overhead.



The Procedure
-------------------------------------------------------------------------------------
-- Script: contig.txt
-- Author: Howard J. Rogers
-- Date: 8th March 2002
-- Copyright: (c) Howard J. Rogers

-------------------------------------------------------------------------------------
-- This script creates a procedure called 'contest'. It was designed to
-- allow you to test the oft-quoted myth that having lots or few extents
-- makes a difference to query and DML performance. It was also designed
-- to put an end to the nonsense that having a segment's extents 'contiguous'
-- with each other in the tablespace makes a performance difference.

-- The procedure therefore creates a number of tables. First, it creates
-- them so that each table's extents are contiguous with each other. It
-- then times selects and deletes. Then it drops the tables, and re-creates
-- them so that their extents are interleaved with the extents of other
-- tables. This is the discontiguous test.

-- The script accepts 4 parameters: The number of tables to test with, the
-- tablespace they should be created in, how many records they should be
-- populated with, and where, on the server, the results should be written to
-- (you specify the same directory as your UTL_FILE_DIR init.ora parameter is set to,
-- the results then get written to a file called contest.txt in that directory).

-- For accurate results, it is suggested that you run the test using a brand new
-- User account, and a brand new tablespace.

-- The user account needs the following permissions

-- Grant create session, create procedure to USER;
-- Grant select any table, create any table, delete any table to USER;
-- Grant drop any table to USER;
-- Grant execute on dbms_utility to USER;
-- Alter user USERNAME quota unlimited on TABLESPACE;

-- The key point is that these permissions must be directly granted to the user,
-- not acquired via a role. There should be no quota restrictions for the user
-- on the tablespace you propose to use for the test.

-- The tablespace to be used can be created however you like. I suggest something
-- like the following:

-- create tablespace CONTEST1 datafile 'd:somewherefilename1.dbf'
-- size 500m autoextend on next 500m extent management local uniform size 64k;

-- ...but dictionary managed tablespace is fine, too. You could also try creating
-- a number of tablespaces with a variety of extent sizes: by running the procedure
-- a number of times, you'll then be able to see whether extent size and numbers
-- have a performance impact.

-- The procedure performs 3 test runs using the one set of run-time parameters.
-- Obviously, you want nothing else running on the machine during run-time.

-- You are responsible for tidying up after the procedure. Whilst it drops the
-- test tables for you, it doesn't get rid of the tablespace, and it doesn't get
-- rid of the user account you created to run it.

-------------------------------------------------------------------------------------



create or replace procedure contest (segs number, tblspc varchar2, numrecs number, fdir varchar2)
as

starttime number default dbms_utility.get_time;
endtime number default dbms_utility.get_time;
deltime number(6,2);
reccnt number;
tottime number :=0;
avgtime number :=0;
iterations number :=0;
objcnt number :=0;
excnt number :=0;
output utl_file.file_type;

begin

output := utl_file.fopen( fdir, 'contest.txt','w',32000);

--determine number of iterations to get requested rows per table

For x in 1 .. 3 loop

execute immediate 'select count(*) from all_objects' into objcnt;
iterations:=round(numrecs/objcnt);

--contiguous

utl_file.put_line(output,'Test Run '||x||' Started : '||dbms_utility.get_time);

for i in 1 .. segs loop
execute immediate 'create table CON'||i||' tablespace '||tblspc||' as select * from all_objects';
for j in 1 .. iterations loop
execute immediate 'insert into CON'||i||' select * from all_objects';
execute immediate 'commit';
end loop;
end loop;

execute immediate 'select count(*) from user_extents' into excnt;
excnt:=excnt/segs;
utl_file.put_line(output,'------------------------------------------------------');
utl_file.put_line(output,excnt ||' CONTIGUOUS EXTENTS ');

starttime:=dbms_utility.get_time;
execute immediate 'select count(*) from CON'||i into reccnt;
utl_file.put_line (output,reccnt||' records for Table CON'||i||' selected in '|| round( (dbms_utility.get_time-
starttime)/100,2) || ' seconds');
tottime:=tottime+round( (dbms_utility.get_time-starttime)/100,2);
end loop;

avgtime:=tottime/segs;
utl_file.put_line (output,'Average select time for all tables: '||avgtime||' seconds.');
tottime:=0;

execute immediate 'delete from CON'||i;
utl_file.put_line (output,reccnt||' records for Table CON'||i|| ' deleted in ' || round( (dbms_utility.get_time-
end loop;



utl_file.put_line (output,'Average delete time for all tables: '||avgtime||' seconds.');
tottime:=0;

--Cleanup

execute immediate 'drop table CON'||i;
end loop;

--discontiguous
utl_file.put_line(output,excnt||' DISCONTIGUOUS EXTENTS ');

execute immediate 'create table CON'||i||' tablespace '||tblspc||' as select * from all_objects';
end loop;

for j in 1 .. iterations loop
execute immediate 'insert into CON'||i||' select * from all_objects';
end loop;
end loop;

execute immediate 'select count(*) from CON'||i into reccnt;
utl_file.put_line (output,reccnt||' records for Table CON'||i||' selected in '|| round( (dbms_utility.get_time-
end loop;

utl_file.put_line (output,'Average select time for all tables: '||avgtime||' seconds.');
tottime:=0;

execute immediate 'delete from CON'||i;
utl_file.put_line (output,reccnt||' records for Table CON'||i|| ' deleted in ' || round( (dbms_utility.get_time-
end loop;

utl_file.put_line (output,'Average delete time for all tables: '||avgtime||' seconds.');

--Cleanup

execute immediate 'drop table CON'||i;
end loop;

end loop;

utl_file.fflush(output);
utl_file.fclose(output);

end;
/


The impact of extent contiguity on performance

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (11)

Destaque

Destaque (10)

Semelhante a The impact of extent contiguity on performance

Semelhante a The impact of extent contiguity on performance (20)

Mais de oracle documents

Mais de oracle documents (20)

The impact of extent contiguity on performance