eygle.com   eygle.com
eygle.com eygle
eygle.com  
 
Digest Net: January 2012 Archives

January 2012 Archives

The difference between UTF8 and AL32UTF8

The difference between UTF8 and AL32UTF8 are:

UTF8 stores Unicode characters with code points > U+FFFF as two surrogate characters, three bytes each

AL32UTF8 stores Unicode characters with code points > U+FFFF as one four-byte character

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

作者:NinGoo 链接:http://www.ningoo.net/html/2009/ora-600_4000_affter_redo_corruption.html

据说今天是光棍节,逢年过节,必有大事。快下班的时候,一位朋友碰到了一个大问题,数据库服务器异常断电重启以后,数据库无法启动,报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了一张表。。。


Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of entries from January 2012 listed from newest to oldest.

December 2011 is the previous archive.

February 2012 is the next archive.

回到 首页 查看最近文章或者查看所有归档文章.