sys_guid (), 8i 后提供。
 
　　Oracle8i引入了SYS_GUID这个概念，它同Oracle管理员所使用的传统的序列（sequence）相比具有诸多优势。一个序列生成器只是简单地创建从给定的起点开始的一系列整数值，而且它被用在选择陈述式的时候自动地递增该系列。
　　
　　序列生成器所生成的数字只能保证在单个实例里是唯一的，这就不适合将它用作并行或者远程环境里的主关键字，因为各自环境里的序列可能会生成相同的数字，从而导致冲突的发生。 SYS_GUID会保证它创建的标识符在每个数据库里都是唯一的。
　　
　　此外，序列必须是DML陈述式的一部分，因此它需要一个到数据库的往返过程（否则它就不能保证其值是唯一的）。SYS_GUID源自不需要对数据库进行访问的时间戳和机器标识符，这就节省了查询的消耗。
　　
　　create table use_seq_table(id integer);
　　create sequence use_seq_sequence;
　　insert into use_seq_table values (use_seq_sequence_value.nextval);
　　
　　REM - for some reason, the documentation uses raw(32)
　　create table use_guid_table (id raw(16));
　　insert into use_guid_table(sys_guid());
　　
　　很多应用程序都依靠序列生成器来创建数据行的主关键字，这些数据行没有一个明显的主值，这也就是说，在这样的数据集里一条记录的创建就会让数据列发生改变。因此，管理员可能会对在表格中将SYS_GUID用作主关键字而不使用序列数感兴趣。这在对象在不同机器的不同数据库里生成以及需要在后来合并到一起的情况下很有用。
　　
　　但是，SYS_GUID所生成的值是一个 16个字节的原始值。序列所生成的整数不会使用16字节（的值），除非它达到了10的30次方（每个字节两个１６进制显示位），而且数字是相当独特的：
　　
SQL> select dump(123456789012345678901234567890) from dual;
　　
DUMP(123456789012345678901234567890)
--------------------------------------------------------------
Typ=2 Len=16: 207,13,35,57,79,91,13,35,57,79,91,13,35,57,79,91
 
顺便按如下方法说一下ＲＡＷ类型：
SQL> create table test_raw (raw_col raw(10));
表已创建。
SQL> insert into test_raw values (hextoraw('ff'));
已创建 1 行。
SQL> insert into test_raw values (hextoraw('0'));
已创建 1 行。
SQL> insert into test_raw values (hextoraw('23fc'));
已创建 1 行。
SQL> insert into test_raw values (hextoraw('fffffffffff'));
已创建 1 行。
SQL> insert into test_raw values (hextoraw('ffffffffffffffffffff'));
已创建 1 行。
SQL> insert into test_raw values (utl_raw.cast_to_raw('051'));
已创建 1 行。
SQL> select raw_col, dump(raw_col, 16) dump_raw from test_raw;
RAW_COL DUMP_RAW
-------------------- -----------------------------------------------
FF Typ=23 Len=1: ff
00 Typ=23 Len=1: 0
23FC Typ=23 Len=2: 23,fc
0FFFFFFFFFFF Typ=23 Len=6: f,ff,ff,ff,ff,ff
FFFFFFFFFFFFFFFFFFFF Typ=23 Len=10: ff,ff,ff,ff,ff,ff,ff,ff,ff,ff
303531 Typ=23 Len=3: 30,35,31
已选择6行。
　　RAW类型的存储很简单，如上面DUMP出来的一样，对应关系很清楚。当使用HEXTORAW时，会把字符串中数据当作16进制数。而使用UTL_RAW.CAST_TO_RAW时，直接把字符串中每个字符的ASCII码存放到RAW类型的字段中。如下所述：
SQL> insert into test_raw values (hextoraw('gg'));
insert into test_raw values (hextoraw('gg'))
*
ERROR 位于第 1 行:
ORA-01465: 无效的十六进制数字
 
SQL> insert into test_raw values (utl_raw.cast_to_raw('gg'));
已创建 1 行。
　　可以看到前面说的，hextoraw是“１６进制所见为所得”，而 utl_raw.cast_to_raw 是“ASCII码直存”。
　　
　　再顺着上面关于SYS_GUID的用法。
　　较短的值就意味着用于表格和索引的存储空间更少，以及查询访问的时间更短。
　　
　　使用SYS_GUID或者序列会在数据库使用周期里的某些地方造成性能上的消耗；问题就是在哪里。对于SYS_GUID而言，性能上的影响在查询时间和创建时间上（在表格里要创建更多的块和索引以容纳数据）。对序列而言，性能上的影响在查询期间，在这个时候，SGA序列的缓冲区被用光。在缺省情况下，一个序列一次会缓冲20个值。如果数据库没有使用这些值就关闭了，它们就会被丢失。
　　
　　SYS_GUID生成的值的另一个显著的不足之处是，管理这些值会变得困难得多。你必须（手动）输入它们或者通过脚本来填充它们，或者将它们作为Web参数来传递。
　　
　　出于这些原因，将SYS_GUID作为一个主关键字不是一个很好主意，除非是在一个并行的环境里或者希望避免使用管理序列生成器的情况下。
 
　　不过，使用SYS_GUID来做主键也不是不可以，但需要先转为 varchar2 较好。最好在使用时显示转换一下，直接使用ＲＡＷ显然是不合适的。
 
　　例如使用时可以这样引用: substr(sys_guid, 1, 32), 这样显示转换一下下。直接插 raw 进入 varchar2 字段， 发生隐式的转换，总不是太妥。曾见过因为大量隐式转换导致最后数据库崩溃，当然事后看是数据库的bug了。