The database character set controls (and specifies) the character set of CHAR & VARCHAR2 columns.
The national character set controls the character set of NCHAR & NVARCHAR2 columns.
CREATE OR REPLACEPROCEDURE test IS
charcol
CHAR(32767);
charvaryingvar
CHAR VARYING(32767);
charactervar
CHARACTER(32767);
charactervaryingvar
CHARACTER VARYING(32767);
nationalcharvaryvar
NATIONAL CHAR VARYING(32767);
nationalcharactervaryingvar NATIONAL CHARACTER VARYING(32767);
ncharvar
NCHAR(32767);
ncharvaryingvar
NCHAR VARYING(32767);
nvarchar2var
NVARCHAR2(32767);
stringvar
STRING(32767);
varcharvar
VARCHAR(32767);
varchar2var
VARCHAR2(32767); BEGIN NULL; END test;
/
Numeric Data Types
precision 1 to 38
scale -84 to 127
Data Type Definition
Variable Size
Column Size
Integer
PLS_INTEGER
or BINARY_INTEGER
(Signed integer 32
bits)
SQL> desc test
Name
Type
------------------- --------------
DATE_COL
DATE
INT_D2S_COL INTERVAL DAY(2) TO SECOND(6)
INT_Y2M_COL INTERVAL YEAR(2) TO MONTH
TS_COL
TIMESTAMP(6)
TSWTZ_COL TIMESTAMP(6) WITH TIME ZONE
TSWLTZ_COL TIMESTAMP(6) WITH
LOCAL TIME ZONE
Since Oracle 7 the DATE datatype is stored in a proprietary format. DATE values
are always stored in 7 bytes, excluding the length byte, within a
datafile. These bytes store the century, year, month, day, hour, minute, and second
details respectively. The following is the definition of Oracle's internal DATE storage structure:
BYTE Meaning
---- -------
1 Century -- stored in excess-100 notation
2 Year -- " "
3 Month -- stored in 0 base notation
4 Day -- "
"
5 Hour -- stored in excess-1 notation
6 Minute -- "
"
7 Second -- "
"
Note that the century and year components are stored in 'excess 100 format',
which means that 100 must be deducted from the byte's value. If a negative number results, then we've got a BC date at which point we take the absolute
number. Also, to avoid ever having a zero byte, 1 is added to the hour, minute and second bytes. Therefore, 1 must be detected to get the correct value.
For example, take the following date again:
17-DEC-1980 00:00:00
we would expect this date to be stored internally as follows:
119, 180, 12, 17, 01, 01, 01
Let's confirm that hypothesis by dumping the data block in question from an
Oracle 8 database and examining its contents. Let's use the "SCOTT.EMP" table for our example:
1) First let's select a row with DATE information to examine:
SQL> desc emp
Result: We see that the HIREDATE column is the fifth column.
SQL> SELECT to_char(hiredate, 'DD-MON-YYYY HH24:MI:SS') FROM emp WHERE rownum = 1;
Result: 17-DEC-1980 00:00:00
2) Next we need to dump the datablock in question:
As a result, we have proven our assumption for the date "17-DEC-1980 00:00:00".
The above method is quite tedious. Is there no easier means of viewing internal
date information? Let's try using the DUMP() function to do the same thing. Issue the following statement:
What happened? Is the information above incorrect or does the DUMP() function
not handle DATE values? No, you have to look at the "Typ=" values to understand why we are seeing these
results. The datatype returned is 13 and not 12, the external DATE datatype. This occurs because we rely on the
TO_DATE function! External datatype 13 is an internal c-structure whose length varies depending on how the c-compiler
represents the structure. Note that the "Len=" value is 8 and not 7. Type 13 is not a part of the published 3GL
interfaces for Oracle and is used for date calculations mainly within PL/SQL operations. Note that the same result
can be seen when DUMPing the value SYSDATE.
Using deductive logic, we can derive the following storage format for type 13 data:
Byte 1 - Base 256 year modifier
2 - Base 256 year
3 - Month
4 - Day
5 - Hours
6 - Minutes
7 - Seconds
8 - Unused
For AD dates, the year and base 256 modifier are stored in base 0 notation and
we must add the modifier to the year to obtain the true year. For BC dates, the year and base 256 modifier are stored in excess-255 notation. We must subtract
the modifier from the year to obtain the true year.
For our year 1980, we could read this to be, Byte 1 + Byte 2 * 256. In other words, 188 + 7 * 256 = 1980.
Let's try another DUMP but using a date extracted from the original table:
Now we have a datatype 12 with a length of 7 and the results are as expected.
In terms of limits, Oracle is capable of handling dates from:
01-JAN-4712 BC 00:00:00
Julian Day: 1
through
31-DEC-9999 AD 23:59:59 AD
Julian Day: 5373484
The Julian Day number is a count of days elapsed since Greenwich mean noon
on 1 January 4712 B.C. in the Julian proleptic calendar. The Julian Date is the Julian Day number followed by
the fraction of the day elapsed since the preceding noon.
All calculations made on DATE values are based on fractional days. In other words, the values of SYSDATE+1 is
tomorrow's DATE at this time. This is reminicent of the Julian Day number behavior described above. By using
the widely accepted convention of the Julian calendar that 1 day is the basic unit of time measurement, DATE
calculation logic is greatly simplified.
Note: Rowid consists of
four parts ... characters 1-6 = data object id, characters 7-9 = file number, characters
10-15 = block, characters 16-18 - row number
Oracle Supplied Data Types
Polymorphic Types
Data Type Definition
Description
SYS.ANYTYPE
Can contain a type description of any persistent SQL type, named or unnamed, including
object types and collection types. Only new transient types can be constructed using the ANYTYPE interfaces.
SYS.ANYDATA
See link at page bottom
SYS.ANYDATASET
Contains a description of a given type plus a set of data instances of that type. An
ANYDATASET can be persistently stored in the database or can be used as an interface parameter to communicate
self-descriptive sets of data, all of which belong to a certain type.
Media Types
Data Type Definition
Description
ORDAudio
Supports the storage of audio data
ORDDoc
Supports the storage and management of any tpe of media
data, including audio, image, and video
ORDImage
Supports the storage of image data
ORDImageSignature
Supports the a compact representation of color, texture, and shape information of image data data
SI_AverageColor
Characterizes an image by its average color
SI_Color
Encapsulates color values
SI_ColorHistogram
Characterizes an image by the relative frequencies of the color exhibited by samples of the raw image
SI_FeatureList
For up to 4 image features represented by SI_AVERAGE_COLOR, SI_COLORHISTOGRAM, SI_POSITIONAL_COLOR
and SI_TEXTURE where the feature is associated with a feature weight
SI_PositionalColor
Given an image divided into rectangles, represents the feature that characterizes an image by
the n by m most significant colors of the rectangles.
SI_StilImage
Represents digital images with inherent image characteristics such as
height, width, and format
SI_Texture
Characterizes an image by
the size of repeating items (coarseness), brightness
variations (contrast), and predominant direction
(directionality)
ORDVideo
Supports the storage of video data
Spatial Types
Data Type Definition
Description
SDO_GEOMETRY
A geometric description of a spatial object stored in a single row
Predefined Composite Data Types
- Data types that contain internal components
Single And Two Dimensional Arrays
RECORD: A composite variable that
can store data values of different types. In PL/SQL records are useful
for holding data from table rows. For ease of maintenance they can be
declared with %ROWTYPE.
set serveroutput
on
DECLARE TYPE TimeType IS RECORD (seconds SMALLINT := 0,
minutes
SMALLINT := 0, hours SMALLINT := 0);