Skip to Main Content
  • Questions
  • Strange behavior of vsize() function.

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, ASHISH.

Asked: March 22, 2003 - 3:12 pm UTC

Last updated: January 05, 2012 - 10:06 am UTC

Version: 9.0.1

Viewed 1000+ times

You Asked

While experimenting with datatype sizes in Oracle 9i(9.0.1) & Oracle 8i(8.1.6), I came accross a strange thing.
When I issued the following query -
"select vsize(hiredate) from emp;" , I got the result as 7.
But on issuing the following query :-
"select vsize(sysdate) from dual;" , I got the result as 8.

Since both "sysdate" as well as "hiredate" (in adove querries) return "date" datatype, then why both querries show different results?.
NOTE : "hiredate" column in above "emp" table has "date" datatype.

I would be very pleased if you could clarify this doubt. My email address is ashish_g7@yahoo.com.

Thanking you,
yours sincerely,
Ashish Gharde.




and Tom said...

Look at the datatype code from a dump - sysdate is different from a date. sysdate is "special", it is an internal (memory) datatype, a little different from an on disk date.

ops$tkyte@ORA920> create table t ( x date );
Table created.

ops$tkyte@ORA920> insert into t values ( sysdate );
1 row created.

ops$tkyte@ORA920> select dump(x), dump(sysdate) from t;

DUMP(X)
-----------------------------------------------------------------------------------------------------------------------------------
DUMP(SYSDATE)
-----------------------------------------------------------------------------------------------------------------------------------
Typ=12 Len=7: 120,103,3,23,18,28,34
Typ=13 Len=8: 211,7,3,23,17,27,33,0


My advice -- just "ignore" it. Not really relevant to you or I in the grand scheme of things.

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

sysdate

bhabani, March 23, 2003 - 8:08 pm UTC

as tom showed in DUMP(), SYSDATE takes one byte more to store the 'size of the date(which is 7bytes )'. So in SYSDATE numeric '7' is extra.

Regds


Thanks for reviewing.

ASHISH .O. GHARDE, March 28, 2003 - 3:29 pm UTC

Thanks for finding time to personally attend my question. The analysis you provided was really informative and knowledge boosting. The way in which you used the "dump()" function was simply great. The knowledge provided by your analysis will greatly help in my future experiments & endeavours. And last but not the least, Thanks for yor advice, that's one thing that's really practical, after all.

Date datatype length 8 when using functions

Ashwani, August 14, 2003 - 1:10 am UTC

PL see the following I am not able to under stand

step1 --------------
select data_length from user_tab_columns where 
data_type='DATE';

DATA_LENGTH
-----------
7

step2 --------------

create table xyz
(a date);

Table created

step3 --------------

insert into xyz values (to_date('10-aug-03'))

1 row created

step4 --------------

SQL> select distinct(data_length) from user_tab_columns where 
2 data_type='DATE';

DATA_LENGTH
-----------
7

step5 --------------

create or replace view temp as (Select trunc(A) as a from xyz);

view created

step 6
SQL> select distinct(data_length) from user_tab_columns where
2 data_type='DATE';

DATA_LENGTH
-----------
7
8
step 7

select TABLE_NAME,COLUMN_NAME 
from user_tab_columns where
data_type='DATE' and data_length=8;


The data length for date column shows 8 when we use truc(date_column) in a view..
As oracle uses 7 bytes to store a date type
usage 
century year month date hour minute second

pls guide where has the length increased to 8..

when i use the dump function i see eight bytes of storage and in normal seven bytes of storage.. using excess-100 in case of century and year and using excess 1 in case of hour and minute..

Strange beahviour.. Only a master can help..

Regards,
Ashwani  

Tom Kyte
August 14, 2003 - 7:57 am UTC

it just is. it always has been. it is not at all a teeny bit relevant to us, it affects nothing in our code, nothing anywhere.


the variable DATE is 8 bytes
the stored data DATE is 7

Incomplete response causes questions to remain

Dave, January 04, 2012 - 1:40 pm UTC

You said: My advice -- just "ignore" it (the difference between 7-byte DUMP(<date-column>) and 8-byte DUMP(sysdate)). Not really relevant to you or I in the grand
scheme of things.

Maybe it is "not really relevant to you or ME in the grand scheme of things," but we still want to know what accounts for the extra 1 byte of consumption for DUMP(sysdate). If there is no rationale for the extra byte, other than "extra byte is used for Oracle Magic", then the response leaves readers wondering...it makes us wonder if the responder knows the answer herself/himself.
Tom Kyte
January 04, 2012 - 3:37 pm UTC

sysdate is not data stored on disk, it is a special psuedo column, a statement level deterministic function - it is not a date coming from a table, it is a thing returned by a statement level deterministic function.

It has an entirely different datatype marker, they are not the same. Look at the values even:

ops$tkyte%ORA11GR2> select dump(sysdate,16), dump(x,16) from t;

DUMP(SYSDATE,16)
-------------------------------------------------------------------------------
DUMP(X,16)
-------------------------------------------------------------------------------
Typ=13 Len=8: dc, 7,1,4,10,22,1e,0
Typ=12 Len=7: 78,70,1,4,11,23,1f


that is century, year, month, day, hour, minute, second, <extra for sysdate>.

Note how the century, year are encoded differently.
As are the hour/minute and probably seconds.

they are just different.

which is basically what I said originally. sysdate isn't a date from disk. a date from disk isn't sysdate. A sysdate can be assigned to a date, but sysdate itself isn't a date stored on disk.

Just my opinion

Michel Cadot, January 05, 2012 - 7:08 am UTC


As I was a system developer when Oracle was first written I give you my opinion.
Why 8 bytes for SYSDATE? Because 8 bytes is a multiple of processor word and so it is easier and faster for processor (and developer) to manage word aligned variables and function returned values.
Why 7 bytes for stored? Because we don't need more and a byte is a byte in the time when disk space was expensive.

Just my 2 cents to remove mental clutter.

Regards
Michel


Tom Kyte
January 05, 2012 - 10:06 am UTC

that is a good guess - but doubtful, the first machine was a pdp-11 - a 16bit machine. But it also ran on 8bit machines in 512k of memory back then too....

The size/shape of all of the data structures change from platform to platform/release to release.

possible, but in my opinion, not probable. And it doesn't explain the different representation.

it is just an implementation detail that doesn't really affect us.


and you know what, I don't know why, I don't care that I don't know, could I find out - probably - but I won't (not worth my cycles) - and I don't know why it is relevant whether I know or not. The fact remains:

My advice -- just "ignore" it. Not really relevant to you or I in the grand
scheme of things.


it is an implementation detail that bears no relevance on our lives.


More to Explore

Performance

Get all the information about database performance in the Database Performance guide.