UTF8 will not be updated anymore when new Unicode versions are released, only AL32UTF8 and AL16UTF16 will.

Due to compatibility problems with pre-9i versions use UTF8 if you have Oracle8i clients connecting to the database. Use AL32UTF8 in pure Oracle9i environment.

UTF-8 encoding is variable-width. In UTF-8, each character can be represented by either one, two, or three bytes.

UTF8 is a varying width 1-3 bytes per character Unicode encoding. It is supported for both database and national character sets. It is a binary superset of US7ASCII. UTF8 corresponds to Unicode CESU-8 encoding.

AL32UTF8 is a varying width 1-4 bytes per character. It is supported for CHAR, VARCHAR2, LONG and CLOB only (database character set). It is a binary superset of UTF8 (in 9.2 only) and US7ASCII. AL32UTF8 corresponds to Unicode UTF-8 encoding.

This is what Metalink says. In Note: 237593.1

There is a possible problem for 817 and lower versions: Problems connecting to AL32UTF8 databases from older versions 8i and lower.

The default UTF8 characterset for 9i/10G is AL32UTF8, however this characterset is NOT recognised by any pre-9i clients/server systems.

Oracle recommends that you use UTF8 instead of AL32UTF8 as database characterset if you have 8i (or older) servers and clients connecting to the 9i/10g system until you can upgrade the older versions.

UTF8 is unicode revision 3.0 in 8.1.7 and up. AL32UTF8 is Unicode 3.0 in 9.0.1, Unicode 3.1 in 9.2, Unicode 3.2 in 10.1 and Unicode 4.01 in 10.2

Besides the difference in Unicode version the "big difference" is that AL32UTF8 has build in support for "Surrogate Pairs" (also known as Surrogate characters or "Supplementary characters").
Practically this means that in 99% of the cases you can use UTF8 instead of AL32UTF8 without any problem.

There are only a few situations where Surrogate Pairs are already used on client side. Windows system with HKSCS2001 (hong kong extension) is one of those. Note that you actually can *store* Surrogate Pairs in UTF8 but will store 2 * 3 byte characters and not like AL32UTF8 one 4 byte character.

Note that if you now use UTF8 as database characterset and -in the future you do a roll out of new 9i or higher clients and all your other databases are upgraded to 9i or higher, you can simply do a alter database characterset to go from UTF8 to AL32UTF8 so downtime will be limited to a few minutes if the need to go to AL32UTF8 should arise. There is no performance impact on staying on UTF8

NOTE:
This note is ONLY relevant if you have already a 9i AL32UTF8 database with data in. If you still need to create the 9i system then choose UTF8 instead of AL32UTF8 as database characterset in the database creation assistant.

So, *IF* you have already a 9i system running with AL32UTF8 then you can use the following steps in this note to change the database characterset to UTF8 without losing data.

You can't simply use "ALTER DATABASE CHARACTERSET" to go from AL32UTF8 to UTF8 because UTF8 is a SUB-set of AL32UTF8 (some codepoints which are correct in AL32UTF8 are not known in UTF8)

But again, UTF8 *contains* all characters know in AL32UTF8, the difference between them is pure the way some characters are stored (AL32UTF8 is a bit more efficient for some characters)

So you will run into ORA-12712 if you try alter database ...

Quote from : http://songhefei.itpub.net/post/7281/473958

据说今天是光棍节，逢年过节，必有大事。快下班的时候，一位朋友碰到了一个大问题，数据库服务器异常断电重启以后，数据库无法启动，报ora-600[4000]错误，尝试了使用隐藏参数，还是无法打开。

ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []

从ora-600内部错误的类型可以看到，4000是trasaction undo相关的内部错误。搜索一下可以发现，logzgh同学已经两次碰到过该问题了(第一次，第二次)。看来在异常宕机的情况下，这个问题出现的机率还是比较高的。既然是有先例的，恢复起来应该是没有问题的，这个案例和logzgh的第一个案例基本一样，trace文件里显示也是obj$上有异常事务:

ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1

将trace文件往下翻，可以看到出现问题的block的dump信息，在block的itl中果然有一条活动事务存在。用bbed找到对应块，设置offset到61，将itl的flag从20改为80，重新计算block的checksum并apply。然后尝试重新启动数据库，这次ora-600[4000]错误没有了，报的是ora-600[2662]错误，数据库无法open。2662就比较容易了，网上相关的处理案例已经一大堆了，将数据库启动到mount状态，设置10015事件来调整scn即可

alter session set events '10015 trace name adjust_scn level 1';

如果数据库已经处于open状态，则可以使用如下语句来调整SCN:

alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

再次重新打开库，报ora-600[2256]，继续使用10015事件，这次level设置为(ora-600错误的第三个参数+1)*4

alter session set event '10015 trace name adjust_scn level 20';

重启，报ora-600[4097]错误，好了，现在基本上恢复已经接近尾声了，使用下面几个隐藏参数，可以正常将数据库打开了。接下来就是告诉朋友做全库export/重建库/import了。

_allow_resetlogs_corruption=true
_allow_terminal_recovery_corruption=true
_corrupted_rollback_segments=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$,
 _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)

年关将近，事故高发时期，阿弥陀佛，多求个平安吧。话说这个案例还没来得及些写呢，晚上回家的路上又接到说有人truncate了一张表。。。

　　谁对中国20-40岁女性的身材(三围)最了解?这个人不是别人，而是阿里巴巴的老大马云----他只要下个命令，让数据挖掘工程师把淘宝某段时间内20-40岁女性购买相关商品的数据汇总，再做个简单的挖掘，答案就放在那了。

　　2010年以来，随着凡客、京东与苏宁易购这两类B2C电商的崛起，国内掀起了又一次B2C电商的热潮，与以往的电商热不同，这次电商热的主流 参与者是众多传统企业。面对这种局面，淘宝祭出了建立2年却不温不火的淘宝商城，将其独立拆分运营，旨在吸引更多传统大中企业来此安家落户，而不要自己做 独立电商。

　　但是很显然，淘宝商城是拦不住数以万计、十万甚至百万计的大中小型传统企业最终做独立B2C的趋势的。而且，接下来还会有更多的凡客、京东杀出来。这种趋势是会让马云睡不着觉的，因为这种趋势发展下去，会把淘宝王国一点一点解构掉。

　　为了让自己能睡着觉，马云拿出了一个用他自己的话说是"要让百度睡不着觉"的对策，也就是一淘。一淘的底子实际上是原来淘宝的站内搜索，拆分独立后嫁接了全网搜索尤其是电商网站产品页抓取的技术。一淘的推出，标志着马云第一次大张旗鼓地把触角伸到了非阿里--淘宝体系的独立电商领域。一淘对于马云 来说绝不仅仅是个电商搜索工具，从战略上说，他是希望一淘最终能成为中国电子商务网站的搜索、导航门户。如果能做到这点，纵使独立电商的大潮如何汹涌，马 云都可高枕无忧。

　　但是事情却没那么顺利。一淘一推出就毁誉参半，京东等大型的独立B2C网站首先表示将用技术手段封杀一淘的抓站蜘蛛或爬虫。一淘想从包括京东在内的大小独立电商网站获得什么?京东等抵制一淘的网站捍卫的又是什么?答案很简单：数据。

　　如果你问我马云旗下这些公司最有价值的是什么，我的答案也是：数据。如今很多互联网企业对数据重视程度不断提高，但多数其他互联网企业的数据，其价值都无法与阿里巴巴所掌握的数据相提并论。

　　这里我们回想一句马云在2008年2月的"冷预言"：冬天来了，准备过冬吧。这句话在莺歌燕舞的2008年冒出来，几乎所有的人的反应都是：这是疯人疯语。

　　但令人意想不到的是，半年多后，大洋彼岸就传来了美国次贷危机进而引发全球金融危机的消息。马云为什么能如此先知先觉?答案跟本文开篇部分那个 半开玩笑的问题一样，马云不仅能从淘宝数据知道中国女性的身材情况，他同样能通过阿里巴巴的数据知道海量中小企业的经营状况，甚至能部分地知道美欧等国当 地居民消费力水平的变化。把这些数据结果跟不断恶化的次贷危机趋势一叠加，他就很容易地成了"先知"了。

　　如今业界对阿里巴巴旗下公司的标准描述是：阿里巴巴是中国最大的B2C平台;淘宝是国内最大的C2C平台;支付宝是中国最大的互联网第三方支付工具;拆分出来的淘宝商城有望成为国内最大的B2C平台;而一淘的目标则是成为基于商品搜索的网购门户。

　　把上面描述的加在一起等于什么?等于阿里巴巴通过旗下的各项业务积累了海量网民网购行为特征数据、众多商家的基本交易数据。然后呢?如今中外很多互联网公司手上也都掌握着很多数据，但是，我们也没有看到什么真正的奇迹发生。

　　马云你能创造奇迹吗?如果把阿里系所掌握的所有数据，再配以先进的数据挖掘技术，阿里巴巴将从一个B2B、B2C、C2C交易平台变身成为一家 超级商业智能(BI)企业。从很早开始，阿里内部就建立了强大的数据挖掘部门，其掌握的数据挖掘技术在国内互联网行业内应是数一数二的;其次，今年上半 年，阿里巴巴悄然收购了作针对中小网站流量统计的CNZZ，此举目的很明确，那就是把百万量级的中小网站的数据也逐步整合到阿里的数据体系中。而且，这些 数据不仅仅是部分中小电商网站的数据，更多是海量网民在众多网站间的行为数据。

　　如果这就是马云秘而不宣的下一个梦想，那么一淘的出现就已经暴露了他的新野心。

　　阿里巴巴成立于1999年，是中国最大的电子商务公司，它拥有的互联网用户遍布全球，成立之初只有18人。现在该公司在中国、香港、台湾、日本、韩国、英国和美国等国家和地区已拥有2万多名员工。

　　阿里巴巴走向成功离不开人力资本战略。阿里巴巴一直在努力推进企业价值观和员工素质的融合发展，为不同类型的员工提供不同的职业发展通道和广阔的成长空间，不断满足企业战略发展所需。

　　为了充分发挥人才的价值，更好地管理人力资本，进而提升组织关键能力和核心竞争力，阿里巴巴组织IT 和管理方面的专家进行了人力资源管理的咨询论证，并经过广泛市场调研和严密选型，选择了PeopleSoft HCM软件构建统一的e-HR平台。

　　在甲骨文合作伙伴毕博管理咨询公司的协助下，阿里巴巴实施了核心人力资源管理(Core HR)、薪资与福利管理、电子绩效管理、培训管理等诸多模块，并与财务管理等系统实现了充分集成与全面整合，构建统一规范的e-HR平台，为集团提供了人员信息和组织信息的单一可信数据源，并可与其他系统进行分享。由此，阿里巴巴在全球化背景下的人力资本的理念、价值观体系及相关活动项目都得以充分推行和落实。

　　借助PeopleSoft HCM软件，阿里巴巴成功将e-HR平台推广到包含港台和海外子公司在内的所有子公司，所有分支机构能同时开展人力资源管理工作，实现了整个集团的人力资 源工作流程规范化和自动化，显著提高了人力资源管理的精确性和工作效率，并从容应对了企业员工人数从2000人到2万多人的急剧扩张、业务高速发展、组织 机构和人员全面改制重组的巨大挑战。

　　此外，利用PeopleSoft HCM 电子绩效管理模块，阿里巴巴构建了一个集团统一标准的全过程跟踪绩效管理平台，显著提高了绩效和评估等工作的时效性和可靠性，同时通过全新的绩效考核机制 提升了员工的企业价值观绩效，并通过对人力资源数据的智能分析为管理层战略决策提供了有效支撑。

　　更重要的是，在本次部署PeopleSoft HCM软件中，阿里巴巴通过自主创新不断对新平台进行调整，完善和丰富系统功能，取得了让新平台更加适应集团发展需求的重要成功，如在将原来的一家公司拆 分为集团子公司架构的组织重组过程中，集团内部不断磨合沟通，寻求最佳解决办法，最终圆满完成了架构调整、流程设置、人员配置等。

　　甲骨文高管及客户相关引言

　　阿里巴巴集团e-HR资深经理宗鸣表示："通过实施基于PeopleSoft 人力资源解决方案的e-HR 平台，阿里巴巴的人力资源政策制度和统一流程在整个集团得到了更加有效无误的贯彻，人力资源部门的员工也从事务性的工作中逐步被释放出来，帮助我们实现了'让人力资源管理实践更加开放简单'的目标。"

　　甲骨文公司大中华区人力资本管理业务发展总监叶天禄表示："人才是一个企业保持持续快速发展的关键资本，发现人才、管理人才并给予其符合企业业 务发展所需的技能、发掘人才潜力，成为了每个企业的管理之重。作为同类最佳的人力资本管理软件，Oracle PeopleSoft 企业人力资本管理(HCM)软件，可帮助企业通过对人进行投资而使其增值并创造新的价值，增强企业核心竞争力。"

　　甲骨文公司副总裁及大中华区管理软件业务总经理潘杰君表示："甲骨文全面、开放、集成的应用软件解决方案适用于所有规模的不同行业企业，并为这 些企业提供了全方位的选择。借助甲骨文业界领先的应用软件产品和解决方案，我们致力于帮助更多的客户优化企业绩效，实现显著的业务增长。"

ora-600[25012]错误的本质原因是因为oracle在构造一致读的过程中发现undo block的rdba不对了，说到底还是因为块的损坏，解决方法就是往前递增全库的SCN，使oracle不产生一致读就可以了。当然，如果这个块已经坏的面目全非，那上述这种方法也不一定行。

我们来看一下我构造的这个例子：

SQL_testdb>drop table t1;

Table dropped.

SQL_testdb>create table t1(id number,name varchar2(10));

Table created.

SQL_testdb>insert into t1 values(1,'cuihua1');

1 row created.

SQL_testdb>insert into t1 values(2,'cuihua2');

1 row created.

SQL_testdb>commit;

Commit complete.

SQL_testdb>select * from t1;

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2

这么改：

1、  递增上述两条记录所在的itl的commit SCN;

2、  修改上述两条记录所在的itl的undo block的RDBA；

改完后ora-600[25012]如期而至：

SQL_testdb>select * from t1;

select * from t1

              *

ERROR at line 1:

ORA-00600: internal error code, arguments: [25012], [11], [971], [], [], [],

[], []

此时的解决方法很简单----就是递增全库的SCN不让oracle产生一致读就可以了。

递增完全库的SCN后可以看到ora-600[25012]已经不复存在：

SQL_testdb>select * from t1;

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2

ORA-600 [25012] "Relative to Absolute File Number Conversion Error"

Note: For additional ORA-600 related information please read Note:146580.1

PURPOSE:
  This article discusses the internal error "ORA-600 [25012]", what
  it means and possible actions. The information here is only applicable
  to the versions listed and is provided only for guidance.

ERROR:
  ORA-600 [25012] [a] [b] [c]

VERSIONS:
  versions 8.0 and above

DESCRIPTION:

  We are trying to generate the absolute file number given a tablespace
  number and relative file number and cannot find a matching file number
  or the file number is zero.

ARGUMENTS:
  Arg [a] Tablespace Number
  Arg [b] Relative file number
  Arg [c] Absolute file number (This arg is present is more recent releases)

FUNCTIONALITY:
  KERNEL FILE MANAGEMENT TABLESPACE COMPONENT

IMPACT:
  POSSIBLE PHYSICAL CORRUPTION

SUGGESTIONS:        

  The possibility of physical corruption exists.

  Obtain the trace files and alert.log for this error and log a Service Request
  with Oracle Support Services for diagnosis.

  If the Arg [b] Relative file number returns 0 (zero), look for fake indexes
  that can cause this error.

  The following query list fake indexes :

  select a.*,b.flags from dba_objects a, sys.ind$ b
  where a.object_id = b.obj#
  and bitand(b.flags,4096)=4096;