It’s a combination of my copy and paste error and “reading bytes from right to left” that’s causing the trouble – They’re left to right.

’78 6e 05 18 08 1f 18′ is ’2010-05-24 07:30:23′ (NOT 09:54 as I mistakenly pasted above)

0×78 = 120 = 20 + 100
0x6e = 110 = 10 + 100
ie 0×78 0x6e = 2010
0×05 = May
0×18 = 24
0×08 = 7 + 1
0x1f = 31 = 30 + 1
0×18 = 24 = 23 + 1

Apologies for the copy and paste error and hope this clears things up.

Thank you for stopping by my blog and leaving the comment about the blog article. I hope that your found “Network Monitoring Experimentations 5″ to be decent also – that blog article took a bit longer than this one to put together.

On a side note, it is great to see the uptick of good information about Oracle’s behavior flowing across the Internet in the last couple of years. A portion of that opinion might have to do with the hit or miss nature of some Google searches, so if I find something interesting, I try to link to it so that it is easier to find again later. The new OakTable.net website has an improved Google search feature, so that is now an option in place of a standard Google search (but I will probably continue to link to helpful articles).

A demonstration of what you described (so that hopefully I will remember the next time I encounter this difference):

CREATE TABLE T1 (C1 DATE);
 
INSERT INTO T1 VALUES (TO_DATE('2010-05-24 07:30:23','YYYY-MM-DD HH24:MI:SS'));
 
ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';
 
SELECT
  TO_DATE('2010-05-24 07:30:23','YYYY-MM-DD HH24:MI:SS') MY_DATE,
  DUMP(C1) C1_DUMP,
  DUMP(TO_DATE('2010-05-24 07:30:23','YYYY-MM-DD HH24:MI:SS')) MY_DATE_DUMP
FROM
  T1;
 
MY_DATE             C1_DUMP                            MY_DATE_DUMP
------------------- ---------------------------------- ----------------------------------
2010-05-24 07:30:23 Typ=12 Len=7: 120,110,5,24,8,31,24 Typ=13 Len=8: 218,7,5,24,7,30,23,0

This is the observation that I would have made with the C1_DUMP:

Hex 78 = Dec 120
Hex 6e = Dec 110
Hex 05 = Dec   5
Hex 18 = Dec  24
Hex 08 = Dec   8
Hex 1f = Dec  31
Hex 18 = Dec  24

That exactly matches what was found in the network packet, using your example.

The web page that you linked contains the following:
“Oracle’s stores DATE in total of 7 bytes. Each byte in it stores values for an element of the DATE as follows:
Byte Description
1 Century value but before storing it add 100 to it
2 Year and 100 is added to it before storing
3 Month
4 Day of the month
5 Hours but add 1 before storing it
6 Minutes but add 1 before storing it
7 Seconds but add 1 before storing it”

Which oddly brings me back to my previous investigation that lead to the “brick wall”, reading the bytes from right to left:
’78 6e 05 18 08 1f 18′

23 decimal = 17 hex, off by 1
30 decimal = 1E hex, off by 1
7 decimal = 7 hex, off by 1
24 decimal = 18 hex – just when you think that there is a pattern, a curve ball is thrown, the same value
5 decimal = 5 hex, the same value
… and then we are completely lost.

While searching Google I did find an interesting test case that I posted a year ago, now I have a topic for tomorrow’s blog article.

That is a nice post.

I’m glad you found the sql-only version of translating raw values of oracle data into human readable format helpful and thanks for the link.
I updated the script later, in light of lots of help by others, to handle timestamps too. The update can be found at http://mwidlake.wordpress.com/2010/02/24/update-to-decoding-high-and-low-values/

Thanks,

Martin

The problem you’ve pointed out above is one of those annoying inconsistencies with Oracle. Data type 13 (Typ=13) is an in-memory representation of dates used by PL/SQL and the date functions like TO_DATE. Dan Morgan has more details on Morgan’s library at
http://www.morganslibrary.org/reference/datatypes.html

A DATE data type from a table will be type 12 (and 7 bytes, rather than 8 ) and match my example above. Just try the DUMP function against the date column from your actual table and it should all make sense.

I appreciate your help with decoding the data section of the packet. I admit to not spending very much time as of yet in trying to decode that section of the packet – that process was planned for a later blog article.

My original thought was to experiment with DUMP, something like this:

ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';
 
SELECT
  TO_DATE('2010-05-24 07:30:23','YYYY-MM-DD HH24:MI:SS') MY_DATE,
  DUMP(TO_DATE('2010-05-24 07:30:23','YYYY-MM-DD HH24:MI:SS')) MY_DATE_DUMP 
FROM
  DUAL;
 
MY_DATE             MY_DATE_DUMP
------------------- ----------------------------------
2010-05-24 07:30:23 Typ=13 Len=8: 218,7,5,24,7,30,23,0

This output almost matches the hex numbers that were originally supplied to your anonymous PL/SQL block, and that were originally found in the packet capture:
’78 6e 05 18 08 1f 18′

23 decimal = 17 hex, off by 1
30 decimal = 1E hex, off by 1
7 decimal = 7 hex, off by 1
24 decimal = 18 hex – just when you think that there is a pattern, a curve ball is thrown, the same value
5 decimal = 5 hex, the same value
… and then we are completely lost.

After seeing your reply, I started to think that there must be another way to do this without using an anonymous PL/SQL block – just standard SQL, something like UTL_RAW.CAST_TO_VARCHAR2, but instead casting it to a date. After a couple of minutes of playing around, I searched and ended up on this page: http://mwidlake.wordpress.com/2010/01/03/decoding-high_value-and-low_value/

In short, you saved me a lot of time hopelessly digging around, trying to determine why I was receiving values that did not match the output of DUMP. I am not sure that I would have found the same solution as you did.

The dates and numbers in the packet trace are in the same format you’d find them in a block dump.

For instance, the 7 bytes – 78 6e 05 18 0a 37 18 – represent 2010-05-24 09:54:23 (May 24th).
DBMS_STATS.CONVERT_RAW_VALUE can be used to do the decoding

eg:

declare
   tmp date;
begin
   dbms_stats.convert_raw_value(hextoraw(replace(upper('78 6e 05 18 08 1f 18'),' ')), tmp);
   dbms_output.put_line(TO_CHAR(tmp,'YYYY-MM-DD HH24:MI:SS'));
end;
/

Likewise, c2 03 5a is the number 289. The byte before this is the length byte.

Put that together in an example for your trace:

03 c2 03 5a 05 41 32  38 39 5a 0c 41 32 38 39 5a 20 20 20 20 20 20 20  07 78 6e 05 18 08 1f 18
 
03 = 3 bytes
c2 03 5a = 289 (NUMBER)
05 = 5 bytes
41 32  38 39 5a = 'A289Z' (VARCHAR2)
0c = 12 bytes
41 32 38 39 5a 20 20 20 20 20 20 20 = 'A289Z       ' (CHAR)
07 = 7 bytes
78 6e 05 18 08 1f 18 = '2010-05-24 09:54:23' (DATE)