Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Clarification -- NUMERIC data type always takes up 22 bytes.
Val,
Here are my ideas based on the data you have provided:
4655 * 8192 = 38,133,760
38,133,760 / 1024 = 37,240,000 bytes - which takes you into your seventh
extent.....
So you have about 750k of block headers
About 20 megabytes of index header, rowid etc..
...plus your indexed columns....
and you soon see how to use up disk space!
Hope this helps you out.
Regards
Mark
-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of
Val_Gamerman/Victoria_Financial.VICTORIA_FINANCIAL_at_lnn.com
Sent: 23 October 2000 18:15
To: Multiple recipients of list ORACLE-L
Subject: Clarification -- NUMERIC data type always takes up 22 bytes.
Alright,
My bad - I should have selected vsize(field) to see how much is actully allocated for the data in the column.
However I still have something that I can not explain. I have a table that has a PRIMARY KEY that is too big in my opinion:
The recap:
1. Actual size of the index is ~ 40Mb 2. Actual size of the data that should be stored in the index is ~ 14Mb 3. Index INIT_EXTENT = 10Mb, NEXT = 5Mb, PCT_FREE=0, MIN_EXTENTS = 1 4. Index has just been rebuilt.
Below you can find the results of queries that I ran trying to identify what the problem might be.
If anybody has enough time to spend to look at these I would be very appreciative. It's just it's been driving me nuts ...
Thanks,
Val Gamerman.
Here is the description of the table:
Name Null? Type ------------------------------- -------- ---- D8POLN NOT NULL NUMBER(9) D8SEQN NOT NULL NUMBER(3) D8PACK VARCHAR2(2000) D8DSTS VARCHAR2(1) D8LCUS VARCHAR2(10) D8LCDT DATE D8LCTM VARCHAR2(8)
Or more detailed one:
AGYPKAR D8POLN NUMBER 22 9 0 1 AGYPKAR D8SEQN NUMBER 22 3 0 2 AGYPKAR D8PACK VARCHAR2 2000 3 AGYPKAR D8DSTS VARCHAR2 1 4 AGYPKAR D8LCUS VARCHAR2 10 5 AGYPKAR D8LCDT DATE 7 6 AGYPKAR D8LCTM VARCHAR2 8 7
===========================================================================
==============================
SQL> select count(*) from agypkar;
COUNT(*)
1 select INDEX_NAME, COLUMN_NAME,COLUMN_POSITION, COLUMN_LENGTH
2 from all_ind_columns
3* where table_name = 'AGYPKAR'
SQL> /
INDEX_NAME COLUMN_NAMECOLUMN_POSITION COLUMN_LENGTH
------------------------------ ------------------------------ ------------- -- ------------- AGYPKAR_PK D8POLN 1 22 AGYPKAR_PK D8SEQN 2 22
===========================================================================
==============================
===========================================================================
==============================
===========================================================================
==============================
===========================================================================
==============================
===========================================================================
==============================
What I do NOT understand is why the size of the index is
1 select sum(bytes) from dba_extents
2* where segment_name = 'AGYPKAR_PK'
SQL> /
SUM(BYTES)
------------------------------------------------------------- OR 7 EXTENTS ! ---------------------------------------------------------------1 select count(*) from dba_extents
7
That's roughly 40Mb for 2 million records. I would think that it should be approx. 14Mb according to the data below.
1* select sum(vsize(d8poln)+vsize(d8seqn)) from agypkar SQL> / SUM(VSIZE(D8POLN)+VSIZE(D8SEQN))
14626070
The MIN extents are fine and PCT_FREE is set to 0.
1 select index_name, initial_extent, min_extents, next_extent, pct_free
2 from all_indexes
3* where index_name = 'AGYPKAR_PK'
SQL> /
INDEX_NAME INITIAL_EXTENT MIN_EXTENTS NEXT_EXTENTPCT_FREE
------------------------------ -------------- ----------- ----------- ----- ---- AGYPKAR_PK 10485760 1 5242880 0
What am I missing?
The RECAP:
1. Actual size of the index is ~ 40Mb 2. Actual size of the data that should be stored in the index is ~ 14Mb 3. Index INIT_EXTENT = 10Mb, NEXT = 5Mb, PCT_FREE=0, MIN_EXTENTS = 1 4. Index has just been rebuilt.
Thanks,
Val Gamerman.
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: Val_Gamerman/Victoria_Financial.VICTORIA_FINANCIAL_at_lnn.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and inReceived on Mon Oct 23 2000 - 16:14:08 CDT
![]() |
![]() |