Comments on: System Managed Extent Size – 11g Improvements

By: 碎片(Fragmentation)–介绍 « a db thinker's home

碎片(Fragmentation)–介绍 « a db thinker's home — Tue, 27 Jul 2010 07:18:17 +0000

[...] 假如说,每个区间都只能是64K,这会限制我们将发起的“db file multiblock read”请求的大小吗或者这些请求可以跨越区间边界读取吗?如果这个表空间是有两个(或多个)数据文件组成,而这些区间又是以“轮流”在两个文件之间分配的,这会影响读操作的方式吗?如果我们尝试进行并行表扫描,这些限制在“direct path read”上会不会有所不同呢?如果你的运行系统是一个数据仓库,需要花费大量的时间运行这种操作,那么这些就是你需要回答的问题.(例如,参见我3年前写的关于运行并行查询时的部分IO异常的记录,以及Christian Antognini在大约几年后描述的Oracle 11g中的一个相关改进.) [...]

By: Bradd Piontek

Bradd Piontek — Tue, 20 Jul 2010 17:42:34 +0000

Chris,
Thanks again for another wonderful (albeit a bit old) blog post that I am just running across. I’m used to the 10g way of System managed extents and could find no documentation of 1M being the NEXT extent size. I’m used to seeing NEXT be NULL in *_tables, but in 11.1.0.7, it shows at 1048576 for NEXT and 65536 for Initial (upon creation of a table without specifying any storage parameters).

The impact I see here is why application that create 1000s of tables and indexes but only use a a handful. Sure, everything starts out at 64K but as soon as an extent is needed, the segment shoots up to 1M. Maybe this is desirable behavior on Oracle’s part? It is just a change from what I know of 10g and System managed extents. I guess I’ll have to wait until we get to 11gR2 and deferred segment creation :(

By: Fragmentation 1 « Oracle Scratchpad

Fragmentation 1 « Oracle Scratchpad — Tue, 13 Jul 2010 20:33:46 +0000

[...] I wrote three years ago about some of the anomalies of I/O sizes when running parallel query, and a related enhancement in 11g described by Christian Antognini a couple of years [...]

By: Christian Antognini

Christian Antognini — Mon, 25 Jan 2010 15:44:15 +0000

Hi Merwyn

Sorry, but I don’t understand what do you want to show with your test case. Where is the difference with mine? As I pointed out in the post, the value of the INITIAL parameter is only “fully” used as of 11.1.0.7. At least this is what I see on my test databases… In your case, what happens if you create the table with the following SQL statement? (1M instead of 2M)

create table mytable2 (empno number(2), ename varchar2(100)) tablespace test2 storage (initial 1M);

Cheers,
Chris

By: Merwyn

Merwyn — Thu, 31 Dec 2009 15:39:33 +0000

Just wanted to point out that “Improvement #1″ is not a new feature of 11.1.0.7.
The behaviour is the same in 11g.
Initial size is taken into consideration to determine the number of extents that will be allocated.
The total number of extents allocated will depend if the tablespace is using SYSTEM or UNIFORM size.
The size of the extents that are allocated will depend on the size specified for initial clause.

The following test case show this.

SQL> create tablespace test1 datafile ‘/u02/oradata/ordb/dbfiles/test02.dbf’ size 5m extent management local uniform size 65536;
Tablespace created.

SQL> create table mytable1 (empno number(2), ename varchar2(100)) tablespace test1 storage (initial 2M);
Table created.

SQL> select file_id, extent_id, block_id, blocks, bytes from dba_extents where segment_name = ‘MYTABLE1′;
FILE_ID EXTENT_ID BLOCK_ID BLOCKS BYTES
———- ———- ———- ———- ———-
7 0 9 8 65536
7 1 17 8 65536
7 2 25 8 65536
…….
…….
7 30 249 8 65536
7 31 257 8 65536

SQL> create tablespace test2 datafile ‘/u02/oradata/ordb/dbfiles/test03.dbf’ size 5m;
Tablespace created.

SQL> create table mytable2 (empno number(2), ename varchar2(100)) tablespace test2 storage (initial 2M);
Table created.

SQL> select file_id, extent_id, block_id, blocks, bytes from dba_extents where segment_name = ‘MYTABLE2′;
FILE_ID EXTENT_ID BLOCK_ID BLOCKS BYTES
———- ———- ———- ———- ———-
8 0 9 128 1048576
8 1 137 128 1048576

SQL> select * from v$version;

BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production
PL/SQL Release 11.1.0.6.0 – Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 – Production
NLSRTL Version 11.1.0.6.0 – Production

By: Christian Antognini

Christian Antognini — Sun, 16 Aug 2009 22:00:39 +0000

Hi Philipp

Provided that sensible values for INITIAL and NEXT are specified, I also do not see why uniform extent size tablespaces should be used. So, the main con is that you have to specify them… And, if you look around, I see lot of people that are no longer willing to specify such parameters at the table level.

Cheers,
Chris

By: Entradas de Oracle semana 33 « Gruñidos sobre Oracle y SAP

Entradas de Oracle semana 33 « Gruñidos sobre Oracle y SAP — Sun, 16 Aug 2009 18:43:46 +0000

[...] Antognini nos cuenta unos cambios en como Oracle 11g maneja los tamaños de los extents en System Managed Extent Size – 11g Improvements. Interesante, espero que 11g llegue pronto a SAP (pero todavía hay que esperar unos [...]

By: Log Buffer #158: a Carnival of the Vanities for DBAs | Pythian Group Blog

Log Buffer #158: a Carnival of the Vanities for DBAs | Pythian Group Blog — Fri, 14 Aug 2009 17:40:59 +0000

[...] On Striving for Optimal Performance, Christian Antognini discusses 11g’s improvements to system managed extent size. [...]

By: Blogroll Report 07/08/2009 – 14/08/2009 « Coskan’s Approach to Oracle

Blogroll Report 07/08/2009 – 14/08/2009 « Coskan’s Approach to Oracle — Fri, 14 Aug 2009 16:47:25 +0000

[...] Christian Antognini -System Managed Extent Size – 11g Improvements [...]

By: Philipp

Philipp — Fri, 14 Aug 2009 15:38:15 +0000

Hi Chris,

Very neat explanation! From 11.1.0.7 on, is there really a reason to continue using
“uniform extent size”? It looks like “system managed extent size” with accurate
INITIAL and NEXT values is the way to go. At least I have some difficutlties to see the cons.

Thanks, and have a nice weekend
Philipp