Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

3

积分

0

好友

0

主题
1#
发表于 2012-4-19 11:30:59 | 查看: 8898| 回复: 9
9i rac修改字符集 在不通过重建的情况下 ,直接在现有的环境下面进行修改。大家有没有好的方法。
由于客户的业务停机时间短,数据量大。通过重建的方式修改字符集客户不同意,只能够在现有的环境下面修改。
主机AIX5.3 ha5.4 2个节点的RAC双机环境 oracle 9208  数据存储采用的是裸设备
2#
发表于 2012-4-19 12:47:55
“Oracle9i rac 修改字符集的问题”

原  字符集是 什么?  目标字符集是什么?

9i 具体是什么版本? 9.2.0.1 ~ 9.2.0.8?

回复 只看该作者 道具 举报

3#
发表于 2012-4-19 13:35:10
oracle 9208
字符集 ZHS16GBK升级到GB18030

回复 只看该作者 道具 举报

4#
发表于 2012-4-19 22:01:21
由于这两个字符集之间是子集与超级之间的关系,所以采用metalink 66320.1这篇文档提供的方法即可解决问题。

回复 只看该作者 道具 举报

5#
发表于 2012-4-19 22:03:38
GBK (GB1300.1) is a super set of GB2312 with 21886 characters.
GB18030 is a super set of GBK with 70244 characters.

GB18030是 GBK 的超集,理论上 只要 目标字符集和 源字符集的 superset 就不会造成DB 内数据的corruption 。

但是需要测试。

回复 只看该作者 道具 举报

6#
发表于 2012-4-19 22:09:06
ODM FINDING:


8i/9i only: Changing the Database Character Set or the Database National Character Set in 8i/9i  


If not done already please see first of all this note:

Note:225912.1 Changing the Database Character Set ( NLS_CHARACTERSET )

It contains more general information and links to guides for the most common
characterset changes.

Please note that in 10g and up the "ALTER DATABASE CHARACTER SET" command
is NOT to be used anymore.
The CSALTER script, combined with CSSCAN, is the only way to change the
characterset of a 10g or higher database.

Note:225912.1 Changing the Database Character Set ( NLS_CHARACTERSET )



                    This note is for 8i/9i ONLY.



PURPOSE
=======

To explain how to change the database character set or national character set
of an existing Oracle8(i) or Oracle9i database without having to recreate
the database.


1. SCOPE & APPLICATION
======================

The method described here is documented in the Oracle 8.1.x and Oracle9i
documentation.  It is not documented but it can be used in version 8.0.x.
It does not work in Oracle7.

The database character set is the character set of CHAR, VARCHAR2, LONG,
and CLOB data stored in the database columns, and of SQL and PL/SQL text
stored in the Data Dictionary.  The national character set is
the character set of NCHAR, NVARCHAR2, and NCLOB data.

In certain database configurations the CLOB and NCLOB data are stored
in the fixed-width Unicode encoding UCS-2.  If you are using CLOB or NCLOB
please make sure you read section "4. HANDLING CLOB AND NCLOB COLUMNS"
below in this document.

Before changing the character set of a database make sure you understand
how Oracle deals with character sets. Before proceeding please refer to
note:158577.1 "NLS_LANG Explained (How Does Client-Server Character
Conversion Work?)".   See also note:225912.1 "Changing the Database
Character Set (NLS_CHARACTERSET)" for general discussion about various
methods of migration to a different database character set.

If you are migrating an Oracle Applications instance, read note:124721.1
"Migrating an Applications Installation to a New Character Set" for specific
steps that have to be performed.

If you are migrating from 8.x to 9.x please have a look at
note:140014.1 "ALERT: Oracle8/8i to Oracle9i Using New "AL16UTF16""
and other referenced notes below.

Before using the method described in this note it is essential to do
a full backup of the database and to use the Character Set Scanner utility
to check your data.  See the section "2. USING THE CHARACTER SET SCANNER"
below.

Note that changing the database or the national character set as described
in this document does not change the actual character codes, it only
changes the character set declaration. If you want to convert the contents
of the database (character codes) from one character set to another
you must use the Oracle Export and Import utilities. This is needed,
for example, if the source character set is not a binary subset of
the target character set, i.e. if a character exists in the source
and in the target character set but not with the same binary code.
All binary subset-superset relationships between characters sets
recognized by the Oracle Server are listed in note:119164.1
"Changing Database Character Set - Valid Superset Definitions".

Note:  The varying width character sets (like UTF8) are not supported as
       national character sets in Oracle8(i) (see note:62107.1).
       Thus, changing the national character set from a fixed width
       character set to a varying width character set is not supported
       in Oracle8(i). NCHAR types in Oracle8 and Oracle8i were designed
       to support special Oracle specific fixed-width Asian character sets,
       that were introduced to provide higher performance processing of
       Asian character data. Examples of these character sets are :
       JA16EUCFIXED ,JA16SJISFIXED , ZHT32EUCFIXED.
       For a definition of varying width character sets see also section
       "4. HANDLING CLOB AND NCLOB COLUMNS" below.

WARNING:  Do not use any undocumented Oracle7 method to change
          the database character set of an Oracle8(i) or Oracle9i
          database.  This will corrupt the database.



2. USING THE CHARACTER SET SCANNER
==================================

Install Csscan following Note 458122.1 Installing and configuring CSSCAN in 8i and 9i

To verify that your database contains only valid codes, specify the
new database character set in the TOCHAR parameter and/or the new
national character set in the TONCHAR parameter.  Specify FULL=Y
to scan the whole database.  Set ARRAY and PROCESS parameters
depending on your system's resources to speed up the scanning.
FROMCHAR and FROMNCHAR will default to the original database and
national character sets.

The Character Set Scanner should report only "Changeless" data in
both the Data Dictionary and in application data.  If any Convertible
or Exceptional data are reported, the ALTER DATABASE [NATIONAL]
CHARACTER SET statement must NOT be used without further
investigation of the source and type of these data.

In situations in which the ALTER DATABASE [NATIONAL] CHARACTER SET
statement is used to repair an incorrect database character set
declaration rather than to simply migrate to a new wider character set,
you may be advised by Oracle Support Services analysts to execute
the statement even if Exceptional data are reported.

For more information see also note:225912.1 "Changing the Database
Character Set (NLS_CHARACTERSET)".


3. CHANGING THE DATABASE OR THE NATIONAL CHARACTER SET
======================================================

Oracle8(i) introduces a new documented method of changing the database
and national character sets.  The method uses two SQL statements, which
are described in the Oracle8i National Language Support Guide:

   ALTER DATABASE [<db_name>] CHARACTER SET <new_character_set>
   ALTER DATABASE [<db_name>] NATIONAL CHARACTER SET <new_NCHAR_character_set>

The database name is optional.  The character set name should be specified
without quotes, for example:

    ALTER DATABASE CHARACTER SET WE8ISO8859P1

To change the database character set perform the following steps.  
Note that some of them have been erroneously omitted from the Oracle8i
documentation:

  1. Use the Character Set Scanner utility to verify that your database
     contains only valid character codes -- see "2. USING THE CHARACTER SET
     SCANNER" above.

  2. If you go from a 7/8bit characterset to varying width character set
     (like UTF8, AL32UTF8, JA16EUC, JA16SJIS, ZHT16BIG5, ZHS16GBK, KO16KSC5601...)
     then prepare the CLOB columns for the character set change
     -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below.
     Omitting this step can lead to corrupted CLOB/NCLOB values
     in the database.

     If SYS.JOB$, SYS.METASTYLESHEET or SYS.RULE$ have convertible please
     see note 258904.1 Solving Convertible data in data dictionary objects
     when changing the NLS_CHARACTERSET for the actions that need to be taken.

  3. Make sure the parallel_server parameter in INIT.ORA is set to false
     or it is not set at all.

     If you are using RAC see
     Note:221646.1 Changing the Character Set for a RAC Database Fails with an ORA-12720 Error



  4. For Oracle 9 and up, make sure you are connected "AS SYSDBA" in sqlplus.
     For Oracle 8/8i, make sure you are connected as INTERNAL in svrmgrl.
     Then follow these steps:

     SHUTDOWN IMMEDIATE;
     -- make sure there is a database backup you can rely on, or create one
     STARTUP MOUNT;
     ALTER SYSTEM ENABLE RESTRICTED SESSION;
     ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
     ALTER SYSTEM SET AQ_TM_PROCESSES=0;
     ALTER DATABASE OPEN;     
     ALTER DATABASE CHARACTER SET <new_character_set>;
     -- a alter database takes typically only a few minutes or less,
     -- it depends on the number of columns in the database, not the
     -- amount of data.
     SHUTDOWN;
     -- If you use Oracle8 then also do:
     STARTUP RESTRICT;
     SHUTDOWN;
     The extra restart/shutdown is necessary in Oracle8(i) because of a SGA
     initialization bug which is fixed in Oracle9i.

  5. Restore the parallel_server parameter in INIT.ORA, if necessary.

  6. Restart the database:

     STARTUP;

  7. If necessary, restore CLOB columns -- see "4. HANDLING CLOB AND NCLOB
     COLUMNS" below.

To change the national character set replace the ALTER DATABASE CHARACTER SET
statement with ALTER DATABASE NATIONAL CHARACTER SET.  You can issue both
statements together if you wish.


Error Conditions
----------------

A number of error conditions may be reported when trying to change the database
or national character set.

In Oracle8(i) the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return:

    ORA-01679: database must be mounted EXCLUSIVE and not open to activate

    - if you do not enable restricted session
    - if you startup the instance in PARALLEL/SHARED mode
    - if you do not set the number of queue processes to 0
    - if you do not set the number of AQ time manager processes to 0
    - if anybody is logged in apart from you.

This error message is misleading.  The command requires the database to be
open but only one session, the one executing the command, is allowed.

For the above error conditions Oracle9i will report one of the errors:

    ORA-12719: operation requires database is in RESTRICTED mode
    ORA-12720: operation requires database is in EXCLUSIVE mode
    ORA-12721: operation cannot execute when other sessions are active

Oracle9i can also report:

    ORA-12718: operation requires connection as SYS

if you are not connect as SYS (INTERNAL, "/ AS SYSDBA").

If the specified new character set name is not recognized, Oracle will report
one of the errors:

    ORA-24329: invalid character set identifier
    ORA-12714: invalid national character set specified
    ORA-12715: invalid character set specified

The ALTER DATABASE [NATIONAL] CHARACTER SET command will only work if
the old character set is considered a binary subset of the new character set.
Oracle Server 8.0.3 to 8.1.5 recognizes US7ASCII as the binary subset of
all ASCII-based character sets.  It also treats each character set as
a binary subset of itself.  No other combinations are recognized.
Newer Oracle Server versions recognize additional subset/superset
combinations, which are listed in note:119164.1.

If the old character set is not recognized as a binary subset of
the new character set, the ALTER DATABASE [NATIONAL] CHARACTER SET
statement will return:
   
    - in Oracle 8.1.5 and above:

      ORA-12712: new character set must be a superset of old character set

    - in Oracle 8.0.5 and 8.0.6:

      ORA-12710: new character set must be a superset of old character set

    - in Oracle 8.0.3 and 8.0.4:

      ORA-24329: invalid character set identifier

You will also get these errors if you try to change the characterset of a
US7ASCII database that was started without a (correct) ORA_NLSxx parameter.
See Note:77442.1

It may be necessary to switch off the superset check to allow changes
between formally incompatible character sets to solve certain character set
problems or to speed up migration of huge databases.  Oracle Support Services
may pass the necessary information to customers after verifying the safety
of the change for the customers' environments.

If in Oracle9i an ALTER DATABASE NATIONAL CHARACTER SET is issued and
there are N-type colums who contain data then this error is returned:
ORA-12717:Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists
The error only speaks about Nclob but Nchar and Nvarchar2 are also checked.


4. HANDLING CLOB AND NCLOB COLUMNS
==================================

Background
----------

In a fixed width character set codes of all characters have the same
number of bytes.  Fixed width character sets are: all single-byte
character sets and those multibyte character sets which have names
ending with 'FIXED'.  In Oracle9i the character set AL16UTF16 is also
fixed width.

In a varying width character set codes of different characters may
have different number of bytes.  All multibyte character sets except
those with names ending with FIXED (and except Oracle9i AL16UTF16
character set) are varying width.

Single-byte character sets are character sets with names of the form
xxx7yyyyyy and xxx8yyyyyy.  Each character code of a single-byte
character set occupies exactly one byte.  Multibyte character sets
are all other character sets (including UTF8).  Some -- usually most
-- character codes of a multibyte character set occupy more than
one byte.

CLOB values in a database whose database character set is fixed width
are stored in this character set.

CLOB values in an Oracle 8.0.x database whose database character set
is varying width are not allowed.  They have to be NULL.

CLOB values in an Oracle >= 8.1.5 database whose database character set
is varying width are stored in the fixed width Unicode UCS-2 encoding.

The same holds for NCLOB values and the national character set.

The UCS-2 storage format of character LOB values, as implemented
in Oracle8i, ensures that calculation of character positions in
LOB values is fast.  Finding the byte offset of a character stored
in a varying width character set would require reading the whole LOB
value up to this character (possibly 4GB).  In the fixed width
character sets the byte offsets are simply character offsets
multiplied by the number of bytes in a character code.
In UCS-2 byte offsets are simply twice the character offsets.

As the Unicode character set contains all characters defined in any other
Oracle character set, there is no data loss when a CLOB/NCLOB value
is converted to UCS-2 from the character set in which it was provided
by a client program (usually the NLS_LANG character set).


CLOB Values and the Database Character Set Change
-------------------------------------------------

In Oracle 8.0.x CLOB values are invalid in varying width character sets.
Thus you must delete all CLOB column values before changing the database
character set to a varying width character set.

In Oracle 8.1.5 and later CLOB values are valid in varying width
character sets but they are converted to Unicode UCS-2 before being
stored.  But UCS-2 encoding is not a binary superset of any other
Oracle character set.  Even codes of the basic ASCII characters are
different, e.g. single-byte code for "A"=0x41 becomes two-byte
code 0x0041.  This implies that even if the new varying width
character set is a binary superset of the old fixed width
character set and thus VARCHAR2/LONG character codes remain valid,
the fixed width character codes in CLOB values will not longer
be valid in UCS-2.

As mentioned above, the ALTER DATABASE [NATIONAL] CHARACTER SET
statement does not change character codes.  Thus, before changing
a fixed width database character set to a varying width character set
(like UTF8) in Oracle 8.1.5 or later, you first have to export
all tables containing non-NULL CLOB columns, then truncate these
tables, then change the database character set and, finally, import
the tables back to the database.  The import step will perform
the required conversion.

If you omit the steps above, the character set change will succeed
in Oracle8(i)  (Oracle9i disallows the change in such situation)
and the CLOBs may appear to be correctly legible but as their
encoding is incorrect, they will cause problems in further
operations. For example, CREATE TABLE AS SELECT will not correctly
copy such CLOB columns.  Also, after installation of the 8.1.7.3
server patchset the CLOB columns will not longer be legible.

LONG columns are always stored in the database character set and
thus they behave like CHAR/VARCHAR2 in respect to the character set
change.  BLOBs and BFILEs are binary raw datatypes and their
processing does not depend on any Oracle character set setting.


NCLOB Values and the National Character Set Change
--------------------------------------------------

The above discussion about changing the database character set
and exporting and importing CLOB values is theoretically applicable
to the change of the national character set and to NCLOB values.
But as varying width character sets are not supported as national
character sets in Oracle8(i), changing the national character set
from a fixed width character set to a varying width character set
is not supported at all.


Preparing CLOB Columns for the Character Set Change
---------------------------------------------------

Take a backup of the database.

If using Advanced Replication or deferred transactions functionality,
make sure that there are no outstanding deferred transactions with
CLOB parameters, i.e. DEFLOB view must have no rows with non-NULL
CLOB_COL column; to make sure that replication environment remains
consistent use only recommended methods of purging deferred
transaction queue, preferably quiescing the replication environment.

Then:

- If changing the database character set from a fixed width
  character set to a varying with character set in Oracle 8.0.x,
  set all CLOB column values to NULL -- you are not allowed
  to use CLOB columns after the character set change.

- If changing the database character set from a fixed width
  character set to a varying width character set in Oracle 8.1.5
  or later, perform table-level export of all tables containing
  CLOB columns, including SYSTEM's tables.  Set NLS_LANG
  to the old database character set for the Export utility.
  Then truncate these tables.


Restoring CLOB Columns after the Character Set Change
-----------------------------------------------------

In Oracle 8.1.5 or later, after changing the character set as described
above (steps 3. to 6.), restore CLOB columns exported in step 2.
by importing them back into the database.  Set NLS_LANG to the old
database character set for the Import utility to avoid IMP-16 errors
and data loss.

RELATED DOCUMENTS:
==================



  Note: 62107.1 The National Character Set in Oracle8
  Note:276914.1 The National Character Set in Oracle 9i and 10g

  Note:119164.1 Changing Database Character set - Valid Superset definitions
  Note:118242.1 ALERT: Changing the Database or National Character Set
                  Can Corrupt LOB Values

  Note.158577.1 NLS_LANG Explained (How Does Client-Server Character Conversion Work?)
  Note:140014.1 ALERT: Oracle8/8i to Oracle9i/10g using New "AL16UTF16"
  Note:159657.1 Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9i (incl. 9.2)
  Note:124721.1 Migrating an Applications Installation to a New Character Set

  Oracle8i National Language Support Guide
  Oracle8i Release 3 (8.1.7) Readme
    - Section 18.12 "Restricted ALTER DATABASE CHARACTER SET Command Support
      (CLOB and NCLOB)"
  Oracle8i Documentation Addendum, Release 3 (8.1.7)
    - Chapter 3 "New Character Set Scanner Utility"
  Oracle8i Application Developer's Guide - Large Objects (LOBs), Release 2
    - Chapter 2 "Basic Components"
  Oracle8 Application Developer's Guide, Release 8.0
    - Chapter 6 "Large Objects (LOBs)", Section "Introduction to LOBs"
  Oracle9i Globalization Guide, Release 1 (9.0.1)
  Oracle9i Database Globalization Guide, Release 2 (9.2)

回复 只看该作者 道具 举报

7#
发表于 2012-4-19 22:09:47
ODM FINDING:


Changing the Database Character Set ( NLS_CHARACTERSET )

Applies to:
Oracle Server - Enterprise Edition - Version: 8.1.5.0 and later   [Release: 8.1.5 and later ]
Information in this document applies to any platform.
Purpose
This article gives an overview of methods to change the database character set or to check before exporting/importing between databases with a different NLS_CHARACTERSET..

The current NLS_CHARACTERSET is seen in NLS_DATABASE_PARAMETERS.
select value from NLS_DATABASE_PARAMETERS where parameter='NLS_CHARACTERSET';

Use this note to get a basic understanding of the methods, then use the in-depth notes at the end of this note for specific conversions.

For all questions regarding the NLS_NCHAR_CHARACTERSET please see: Note 276914.1 The National Character Set in Oracle 9i and 10g


To change the NLS_CHARACTERSET for an Oracle Applications database: please see Note 124721.1 Migrating an Applications Installation to a New Character Set.
This is the only way supported by Oracle applications. If you have any doubt log an Oracle Applications SR for assistance.


Scope and Application
Anyone trying to change the NLS_CHARACTERSET.

There are still "dba's" out there who try to change the NLS_CHARACTERSET or NLS_NCHAR_CHARACTERSET by updating props$ . This is NOT supported and WILL corrupt your database. This is one of the best way's to destroy a complete dataset. Oracle Support will TRY to help you out of this but Oracle will NOT warrant that the data can be recoverd or recovered data is correct. You WILL be asked to do a FULL export and a complete rebuild of the database.

Please, do NOT update props$.

Changing the Database Character Set ( NLS_CHARACTERSET )
A) The database character set (NLS_CHARACTERSET)
The NLS_CHARACTERSET of an Oracle database defines what characters can be stored in the database using the CHAR, VARCHAR2, LONG and CLOB datatypes. A Characterset does not define languages, it defines a certain range of characters. Any language that uses only the characters known by that characterset can then be stored.

If you change character sets there is a possibility that characters that you currently use are not defined in the new character set or that the current setup is not correctly used and therefore you could lose data when changing the NLS_CHARACTERSET.

Make sure you do not store "binary" (Encrypted) data in character datatypes (CHAR,VARCHAR2,LONG,CLOB).
If binary data is stored/handled as a CHAR, VARCHAR2, LONG or CLOB datatype then data loss is expected, especially when using an AL32UTF8 database (even without using exp/imp). Or errors like ORA-29275 or ORA-600 [kole_t2u], [34] may appear.

See Note 1297507.1 Problems with (Importing) Encrypted Data After Character Set Change Using Other NLS_CHARACTERSET Database or Upgrading the (client) Oracle Version

You should always check this by using the Character Set Scanner (Csscan) before making any changes to your character set.
Even when using Exp/imp or Expdp/Impdp.

Note 458122.1 Installing and Configuring Csscan in 8i and 9i (Database Character Set Scanner)
Note 745809.1 Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
Note 444701.1 Csscan output explained
B) Choosing a new database character set
For the majority of customers an Unicode character set (AL32UTF8) is the best choice See Note 333489.1 Choosing a database character set means choosing Unicode.

You cannot use AL16UTF16 as NLS_CHARACTERSET, AL16UTF16 is only possible as NLS_NCHAR_CHARACTERSET, see Note:276914.1 The National Character Set in Oracle 9i 10g and 11g

For non-Unicode charactersets the best choice are xx8MSWIN125x charactersets, even if the database itself runs on an Unix platform. The reason is simply that the majority of the clients are windows based systems, hence the best non-Unicode characterset for a database is a characterset that can store all the characters known by those clients, which means an xx8MSWIN125x characterset:

EE8MSWIN1250 , CL8MSWIN1251, WE8MSWIN1252, EL8MSWIN1253 ,TR8MSWIN1254, IW8MSWIN1255, AR8MSWIN1256, BLT8MSWIN1257, VN8MSWIN1258, TH8TISASCII, JA16SJIS , KO16MSWIN949, ZHS16GBK, ZHT16MSWIN950 , ZHT16HKSCS31

Detailed discussion is found in Note 264294.1 Choosing from WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 as db character set.

From 11g onwards the DBCA offers by default a list of "recommended" charactersets to use as NLS_CHARACTERSET which , for the same reason as above, does not included charactersets like WE8ISO8859P1 , note that ALL charactersets are still SUPPORTED and "non recommended" charactersets can be used if needed.
See Note 306411.1 Character Set Consolidation for Oracle Database 11g for more information.
if you need to create a database using one of the "non recommended" charactersets in the DBCA (US7ASCII or WE8ISO8859P1 for example) , then unselect in the "Character Sets" tab the "show recommended character sets only" box in step 9 of 11 of the DBCA.



If you want to know what Languages can be stored in most common charactersets then please see Note 62421.1 Which Character Set Supports Which Language

To know what characters are known in a certain characterset then please see
Note 282336.1 Charts of most current mono-byte Character sets
Or use Locale builder to open the Oracle characterset definition
Note 223706.1 Using Locale Builder to view the definition of character sets

An excellent external resource is http://www.eki.ee/letter/ . The website allows you to choose a language and then gives a overview of all charactersets that contain all the letters needed for this language.
Please note that Oracle does not warrant that the information on this website is accurate.
C) Changing the database character set.

Please see the following note for an Oracle Applications database: Note 124721.1 Migrating an Applications Installation to a New Character Set.
This is the only way supported by Oracle applications. If you have any doubt log an Oracle Applications SR for assistance.


There are 2 basic ways of changing the character set and a third 'combined' way:
C1) Using the "ALTER DATABASE CHARACTER SET" command in 8i or 9i and CSALTER in 10g and 11g.
This is not always possible because seen ALTER DATABASE CHARACTER SET / CSALTER does not (!) change the actual code points of the stored data.

So this method can only be used if the data that is currently stored in the database is a Binary Sub set of the new character set (=all codes (!) of the old characterset are valid and mean the same character in the new characterset, the new characterset is then a strict superset of the old) .

For 8i / 9i this is documented in Note 66320.1 8i/9i only: Changing the Database Character Set or the Database National Character Set in 8i/9i
This can be used for these combinations: Note 119164.1 Changing Database Character Set - Valid Superset Definitions
Note that while it's technically not NEEDED to run Csscan in 8i and 9i we strongly recommend to run csscan.

In 10g and 11g the "ALTER DATABASE CHARACTER SET" command is NOT to be used any more but Csscan/Csalter is the only supported way to change a database characterset.

In order to use Csalter you need first to run csscan
Note 745809.1 Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
and then check the csscan results if you can run Csalter.
Csalter is not depending on the Superset definitions and it takes no arguments.
Csalter IS however depending on the csscan output.

More information about Csscan and Csalter is in Note 444701.1 Csscan output explained
C2) Using Export/Import (or Datapump in 10g and up).
You simply export the current database, then create a new database with the new character set and import the data into that database.

Of course the characters that you are storing will still have to be defined in the new character set AND need to be properly defined in the source database!
This is OFTEN not the case , this can be detected by using csscan upfront on the source database, so when using exp/imp we advice to use always Csscan upfront to detect any possible problems.

If you are exporting/importing certain users or table(s) between existing databases and one database is an UTF8 or AL32UTF8 database then please see:
Note 1297961.1 ORA-01401 / ORA-12899 While Importing Data In An AL32UTF8 / UTF8 (Unicode) Or Other Multibyte NLS_CHARACTERSET Database.

Exp/imp can be used for any change where all characters from the old characterset are know in the new (but they may use different codes for the same character).

When using datapump there is a chance to have data corruption when going
from a 8 bit characterset to UTF8 / AL32UTF8 or an other multibyte characterset on ALL 10g versions (including 10.1.0.5 and 10.2.0.3) and 11.1.0.6. Impdp may provoke data corruption unless you applied Patch 5874989.
The "old" exp/imp work fine. This problem is fixed in the 10.2.0.4 and 11.1.0.7 patchset.

All existing patches for this bug are found here: https://updates.oracle.com/download/5874989.html

For windows the fix is included in
10.1.0.5.0 Patch 20 (10.1.0.5.20P) or later ( Note 276548.1 )
10.2.0.3.0 Patch 11 (10.2.0.3.11P) or later ( Note 342443.1 )

The patch is technically only needed on the impdp side, but if you use expdp/impdp between different character sets we suggest to patch all your systems.

C3) Using a combination of ALTER DATABASE CHARACTER SET (8i, 9i) / CSALTER (10g and 11g) and export/import
In most cases method c1 does not work seen Csscan tells you that some data needs to be converted to the new character set (= "Convertible" data), and method c2 will simply take too much time.
In those cases it is usually possible to use a combination of the 2 methods:

a) Export only the "Convertible" data from the tables that are listed by Csscan (= characters where the CODE changes from between the current and the new characterset)
b) Truncate or drop those tables.
c) Run csscan again to confirm that all data is now ready to be moved to the new character set directly and if that is the case change the character set of the database using the ALTER DATABASE CHARACTERSET (8i,9i) / CSALTER (10g and 11g) command (method C1).
d) Now that the character set has changed we can simply import the data exported in step (a). The import will convert that data so that it gets stored using the correct character codes for this character set.

C4) Step by step guides to do a characterset conversion between 8 bit charactersets in 8i,9i,10g and 11g.
These specific notes can guide you through some often used conversions, they show how to use the the above mentioned "combined method" in practice and document extra checks:

Changing from US7ASCII to WE8MSWIN1252 or other  xxIOS8859Pxx to xx8MSWIN12xx charactersets
Note 555823.1 Changing from US7ASCII or WE8ISO8859P1 to WE8MSWIN1252
Note 1213683.1 Changing from US7ASCII or WE8ISO8859P1 or IW8ISO8859P8 to IW8MSWIN1255
Note 260022.1 Changing From US7ASCII or WE8ISO8859P1 or AR8ISO8859P6 to AR8MSWIN1256

Note 261871.1 Changing EL8ISO8859P7 to EL8MSWIN1253
Note 263119.1 Changing EE8ISO8859P2 to EE8MSWIN1250
Note 266309.1 Changing WE8ISO8859P9 to WE8ISO8859P1/WE8MSWIN1252
Note 246008.1 Changing WE8ISO8859P15 to WE8MSWIN1252

Other combinations:

Note 1104893.1 Changing WE8DEC to WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252

Note 257722.1 Changing WE8ISO8859P1 to WE8ISO8859P15
Note 261639.1 Changing WE8MSWIN1252 to WE8ISO8859P15
Note 273281.1 Changing WE8ISO8859P15 TO WE8ISO8859P1

C5) Step by step guides to do a character set conversion to Unicode (UTF8/AL32UTF8)
For migration to AL32UTF8 (and the deprecated UTF8), there is a new tool available called the Database Migration Assistant for Unicode (DMU). The DMU tool is an unique next-generation migration tool providing an end-to-end solution for migrating your databases from legacy encodings to Unicode.
DMU's intuitive user-interface greatly simplifies the migration process and lessens the need for character set migration expertise by guiding the DBA through the entire migration process as well as automating many of the migration tasks.
The DMU is supported against Oracle 11.2.0.3 and higher and selected older versions and platform combinations.
For more information please see Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool and the DMU pages on OTN.
From Oracle 12c database onwards, the DMU will be the only tool available to migrate to Unicode.

To Change the NLS_CHARACTERSET  to Unicode (= AL32UTF8 or UTF8) in Oracle 8i, 9i, 10g and 11g versions please follow
Note 260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode)

It is strongly adviced to read upfront Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications

The above 2 notes for going to AL32UTF8 can also be used for going to any other varying width characterset like ZHS16GBK, ZHT16MSWIN950, ZHT16HKSCS, ZHT16HKSCS31,KO16MSWIN949, JA16SJIS ...
We strongly suggest however to use AL32UTF8 as NLS_CHARACTERSET, there is no added value in using one of the other varying width charactersets as NLS_CHARACTERSET. Basically AL32UTF8 is "the way forward", AL32UTF8 supports ALL characters defined in any of the other charactersets .

Changing the NLS_CHARACTERSET from AL32UTF8 to UTF8 (or from UTF8 to AL32UTF8) is also simply following Note 260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) .

This is only needed for Oracle RDBMS Version 7 systems: Note 234381.1 Changing NLS_CHARACTERSET from AL24UTFFSS to UTF8 - AL32UTF8

If you have an AL32UTF8 or UTF8 database but it turns out your application is not ready for AL32UTF8 or UTF8 then you can revert this to an other NLS_CHARACTERSET by following.
note 1283764.1 Changing the NLS_CHARACTERSET From AL32UTF8 / UTF8 (Unicode) to another NLS_CHARACTERSET


D) Further reading
There are some additional considerations when you change the character set of an Oracle Applications database, please see the following note for a complete overview of those: Note 124721.1 Migrating an Applications Installation to a New Character Set

Note that display problems are most likely *NOT* resolved by start changing the database characterset.
Instead please check first of all if you can store/retrieve the data using SQLdeveloper, this is a "know good client" that needs no NLS configuration.
You can download it from http://www.oracle.com/technology/products/database/sql_developer/
If the data is displayed correctly in SQLdeveloper then you are sure it's correct in the database and that the current NLS_CHARACTERSET supports the character.
If this is the case then see the following notes to correctly configure your other client(s), you can then use the data entered trough SqlDeveloper as "reference":

Note 158577.1 NLS_LANG Explained (How does Client-Server Character Conversion Work?)
Note 179133.1 The correct NLS_LANG in a Windows Environment
Note 264157.1 The correct NLS_LANG on Unix Environments
Note 229786.1 NLS_LANG and webservers explained.

A more detailed debugging guide is Note 788931.1 Troubleshooting RDBMS (client and server) NLS Problems (Charactersets, sorts, dates, ..)

References
NOTE:124721.1 - Migrating an Applications Installation to a New Character Set
NOTE:282336.1 - Charts of most current mono-byte / 8 bit Character sets
NOTE:444701.1 - Csscan output explained
NOTE:458122.1 - Installing and Configuring Csscan in 8i and 9i (Database Character Set Scanner)
NOTE:60134.1 - Globalization (NLS) - Frequently Asked Questions
NOTE:745809.1 - Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)

回复 只看该作者 道具 举报

8#
发表于 2012-4-19 22:22:57
我这边实在是没有时间测试了 客户也不给测试时间 只能搭建一个单机的环境测试了一下
谢谢Maclean,Liu

回复 只看该作者 道具 举报

9#
发表于 2012-4-19 22:28:09
oracle 字符集 子集 subset  超集 superset 列表

What is a superset?

A superset, in this context, is a character set where every character in the subset character set is defined and is defined at the same code point. This is also called a "strict" superset.
If the change you want to do is not listed here then you CANNOT use "Alter Database Character Set" and need to use Export/Import for at least a part of the data.

Most common changes are documented in NOTE 225912.1 Changing the Database Character Set ( NLS_CHARACTERSET ), each having a full step by step overview of what needs to be done.

This note is relevant to anyone wishing to change the database character set or the database national character set in 8i or 9i .

This note is relevant for 8.1.6 to 9.2.0.8 ONLY.



8.1.6 Subset/Superset Pairs
===========================

A. Current Char set B. New Char set (Strict Superset of A.)
------------------- ---------------------------------------
US7ASCII WE8DEC
US7ASCII US8PC437
US7ASCII WE8PC850
US7ASCII IN8ISCII
US7ASCII WE8PC858
US7ASCII WE8ISO8859P1
US7ASCII EE8ISO8859P2
US7ASCII SE8ISO8859P3
US7ASCII NEE8ISO8859P4
US7ASCII CL8ISO8859P5
US7ASCII AR8ISO8859P6
US7ASCII EL8ISO8859P7
US7ASCII IW8ISO8859P8
US7ASCII WE8ISO8859P9
US7ASCII NE8ISO8859P10
US7ASCII TH8TISASCII
US7ASCII BN8BSCII
US7ASCII VN8VN3
US7ASCII VN8MSWIN1258
US7ASCII WE8ISO8859P15
US7ASCII WE8NEXTSTEP
US7ASCII AR8ASMO708PLUS
US7ASCII EL8DEC
US7ASCII TR8DEC
US7ASCII LA8PASSPORT
US7ASCII BG8PC437S
US7ASCII EE8PC852
US7ASCII RU8PC866
US7ASCII RU8BESTA
US7ASCII IW8PC1507
US7ASCII RU8PC855
US7ASCII TR8PC857
US7ASCII CL8MACCYRILLICS
US7ASCII WE8PC860
US7ASCII IS8PC861
US7ASCII EE8MACCES
US7ASCII EE8MACCROATIANS
US7ASCII TR8MACTURKISHS
US7ASCII EL8MACGREEKS
US7ASCII IW8MACHEBREWS
US7ASCII EE8MSWIN1250
US7ASCII CL8MSWIN1251
US7ASCII ET8MSWIN923
US7ASCII BG8MSWIN
US7ASCII EL8MSWIN1253
US7ASCII IW8MSWIN1255
US7ASCII LT8MSWIN921
US7ASCII TR8MSWIN1254
US7ASCII WE8MSWIN1252
US7ASCII BLT8MSWIN1257
US7ASCII N8PC865
US7ASCII BLT8CP921
US7ASCII LV8PC1117
US7ASCII LV8PC8LR
US7ASCII LV8RST104090
US7ASCII CL8KOI8R
US7ASCII BLT8PC775
US7ASCII WE8DG
US7ASCII WE8NCR4970
US7ASCII WE8ROMAN8
US7ASCII WE8MACROMAN8S
US7ASCII TH8MACTHAIS
US7ASCII HU8CWI2
US7ASCII EL8PC437S
US7ASCII LT8PC772
US7ASCII LT8PC774
US7ASCII EL8PC869
US7ASCII EL8PC851
US7ASCII CDN8PC863
US7ASCII HU8ABMOD
US7ASCII AR8ASMO8X
US7ASCII AR8NAFITHA711T
US7ASCII AR8SAKHR707T
US7ASCII AR8MUSSAD768T
US7ASCII AR8ADOS710T
US7ASCII AR8ADOS720T
US7ASCII AR8APTEC715T
US7ASCII AR8NAFITHA721T
US7ASCII AR8HPARABIC8T
US7ASCII AR8NAFITHA711
US7ASCII AR8SAKHR707
US7ASCII AR8MUSSAD768
US7ASCII AR8ADOS710
US7ASCII AR8ADOS720
US7ASCII AR8APTEC715
US7ASCII AR8MSAWIN
US7ASCII AR8NAFITHA721
US7ASCII AR8SAKHR706
US7ASCII AR8ARABICMACS
US7ASCII LA8ISO6937
US7ASCII JA16VMS
US7ASCII JA16EUC
US7ASCII JA16SJIS
US7ASCII KO16KSC5601
US7ASCII KO16KSCCS
US7ASCII KO16MSWIN949
US7ASCII ZHS16CGB231280
US7ASCII ZHS16GBK
US7ASCII ZHT32EUC
US7ASCII ZHT32SOPS
US7ASCII ZHT16DBT
US7ASCII ZHT32TRIS
US7ASCII ZHT16BIG5
US7ASCII ZHT16CCDC
US7ASCII ZHT16MSWIN950
US7ASCII AL24UTFFSS
US7ASCII UTF8
US7ASCII JA16TSTSET2
US7ASCII JA16TSTSET


8.1.7 Additions
===============

US7ASCII ZHT16HKSCS
US7ASCII KO16TSTSET
WE8DEC TR8DEC
WE8DEC WE8NCR4970
WE8PC850 WE8PC858
D7DEC D7SIEMENS9780X
I7DEC I7SIEMENS9780X
WE8ISO8859P1 WE8MSWIN1252
AR8ISO8859P6 AR8ASMO708PLUS
AR8ISO8859P6 AR8ASMO8X
IW8EBCDIC424 IW8EBCDIC1086
IW8EBCDIC1086 IW8EBCDIC424
LV8PC8LR LV8RST104090
DK7SIEMENS9780X N7SIEMENS9780X
N7SIEMENS9780X DK7SIEMENS9780X
I7SIEMENS9780X I7DEC
D7SIEMENS9780X D7DEC
WE8NCR4970 WE8DEC
WE8NCR4970 TR8DEC
AR8SAKHR707T AR8SAKHR707
AR8MUSSAD768T AR8MUSSAD768
AR8ADOS720T AR8ADOS720
AR8NAFITHA711 AR8NAFITHA711T
AR8SAKHR707 AR8SAKHR707T
AR8MUSSAD768 AR8MUSSAD768T
AR8ADOS710 AR8ADOS710T
AR8ADOS720 AR8ADOS720T
AR8APTEC715 AR8APTEC715T
AR8NAFITHA721 AR8NAFITHA721T
AR8ARABICMAC AR8ARABICMACT
AR8ARABICMACT AR8ARABICMAC
KO16KSC5601 KO16MSWIN949
WE16DECTST2 WE16DECTST
WE16DECTST WE16DECTST2


9.0.1 Additions
===============

US7ASCII BLT8ISO8859P13
US7ASCII CEL8ISO8859P14
US7ASCII CL8ISOIR111
US7ASCII CL8KOI8U
US7ASCII AL32UTF8
BLT8CP921 BLT8ISO8859P13
US7ASCII AR8MSWIN1256
UTF8 AL32UTF8 (added in patchset 9.0.1.2)


Character Set Subset/Superset Pairs Obsolete from 9.0.1
=======================================================

US7ASCII AR8MSAWIN
AR8ARABICMAC AR8ARABICMACT


9.2.0 Additions
===============

US7ASCII JA16EUCTILDE
US7ASCII JA16SJISTILDE
US7ASCII ZHS32GB18030
US7ASCII ZHT32EUCTST
WE8ISO8859P9 TR8MSWIN1254
LT8MSWIN921 BLT8ISO8859P13
LT8MSWIN921 BLT8CP921
BLT8CP921 LT8MSWIN921
AR8ARABICMAC AR8ARABICMACT
ZHT32EUC ZHT32EUCTST
UTF8 AL32UTF8


Character Set Subset/Superset Pairs Obsolete from 9.2.0
=======================================================

LV8PC8LR LV8RST104090

回复 只看该作者 道具 举报

10#
发表于 2012-4-19 22:47:45
手头没有 9i的DB可供测试, 测试了一下在10.2.0.1 上 从 ZHS16BK 修改为 ZHS32GB18030是可行的



SQL> select * from sys.props$ where name='NLS_CHARACTERSET';

NAME
------------------------------
VALUE$
--------------------------------------------------------------------------------
COMMENT$
--------------------------------------------------------------------------------
NLS_CHARACTERSET
ZHS16GBK
Character set



SQL> select   * From v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production


SQL> create table maclean(t1 varchar2(2000));

Table created.

SQL> insert into maclean values('眞');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from maclean;

T1
--------------------------------------------------------------------------------










@?/rdbms/admin/csminst.sql



csscan system/oracle FULL=y FROMCHAR=zhs16gbk TOCHAR=ZHS32GB18030 LOG=char.log CAPTURE=Y ARRAY=1000000 PROCESS=2



Creating Database Scan Summary Report...

Creating Individual Exception Report...

Scanner terminated successfully.









[oracle@vrh8 ~]$ cat char.log.txt
Database Scan Summary Report

Time Started  : 2012-04-19 10:23:32
Time Completed: 2012-04-19 10:31:06

Process ID         Time Started       Time Completed
---------- -------------------- --------------------
         1  2012-04-19 10:23:33  2012-04-19 10:31:05
         2  2012-04-19 10:23:33  2012-04-19 10:31:03
---------- -------------------- --------------------

[Database Size]

Tablespace                           Used            Free           Total       Expansion
------------------------- --------------- --------------- --------------- ---------------
SYSTEM                            231.75M          68.25M         300.00M            .00K
UNDOTBS1                          126.06M          73.94M         200.00M            .00K
SYSAUX                             52.19M          67.81M         120.00M            .00K
TEMP                                 .00K            .00K            .00K            .00K
USERS                              64.00K           4.94M           5.00M            .00K
------------------------- --------------- --------------- --------------- ---------------
Total                             410.06M         214.94M         625.00M            .00K

The size of the largest CLOB is 342472 bytes

[Database Scan Parameters]

Parameter                      Value                                          
------------------------------ ------------------------------------------------
CSSCAN Version                 v2.1                                            
Instance Name                  TESTCHAR                                       
Database Version               10.2.0.1.0                                      
Scan type                      Full database                                   
Scan CHAR data?                YES                                             
Database character set         ZHS16GBK                                       
FROMCHAR                       zhs16gbk                                       
TOCHAR                         ZHS32GB18030                                    
Scan NCHAR data?               NO                                             
Array fetch buffer size        1000000                                         
Number of processes            2                                               
Capture convertible data?      YES                                             
------------------------------ ------------------------------------------------

[Scan Summary]

All character type data in the data dictionary remain the same in the new character set
All character type application data remain the same in the new character set

[Data Dictionary Conversion Summary]

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                       857,490                0                0                0
CHAR                                 0                0                0                0
LONG                            98,144                0                0                0
CLOB                               347                0                0                0
VARRAY                              25                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                          956,006                0                0                0
Total in percentage            100.000%           0.000%           0.000%           0.000%

The data dictionary can be safely migrated using the CSALTER script

[Application Data Conversion Summary]

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                             0                0                0                0
CHAR                                 0                0                0                0
LONG                                 0                0                0                0
CLOB                                 0                0                0                0
VARRAY                               0                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                                0                0                0                0
Total in percentage              0.000%           0.000%           0.000%           0.000%

[Distribution of Convertible, Truncated and Lossy Data by Table]

USER.TABLE                                              Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
-------------------------------------------------- ---------------- ---------------- ----------------

[Distribution of Convertible, Truncated and Lossy Data by Column]

USER.TABLE|COLUMN                                       Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
-------------------------------------------------- ---------------- ---------------- ----------------

[Indexes to be Rebuilt]

USER.INDEX on USER.TABLE(COLUMN)                                                         
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------



[oracle@vrh8 ~]$ cat char.log.err
Database Scan Individual Exception Report


[Database Scan Parameters]

Parameter                      Value                                          
------------------------------ ------------------------------------------------
CSSCAN Version                 v2.1                                            
Instance Name                  TESTCHAR                                       
Database Version               10.2.0.1.0                                      
Scan type                      Full database                                   
Scan CHAR data?                YES                                             
Database character set         ZHS16GBK                                       
FROMCHAR                       zhs16gbk                                       
TOCHAR                         ZHS32GB18030                                    
Scan NCHAR data?               NO                                             
Array fetch buffer size        1000000                                         
Number of processes            2                                               
Capture convertible data?      YES                                             
------------------------------ ------------------------------------------------

[Data Dictionary individual exceptions]


[Application data individual exceptions]







Convertible This data is valid, but the characters will change to a different code point in the new characterset. When using Csalter / "Alter database character set" any User/Application Data that is "convertible" needs to be exported and truncated/deleted before the change of the characterset and imported afterwards.



Truncated  This is a special case of "convertible" data, meaning that the amount of BYTES the data uses will expand in the conversion and the field it presently occupies is not large enough to hold the data post-conversion. Typically this happens when going from a single byte characterset (where one character is one byte) to a multi byte characterset (where on character can be one, two or more bytes) like Unicode (AL32UTF8/UTF8). If you do not take action this you will see ORA-01401: inserted value too large for column or from 10g onwards: ORA-12899: value too large for column during import.
Truncation in Data Dictionary objects is very rare and will be solved by using the steps for convertible Data Dictionary data.

LOSSY data.
This data is not a valid code point for the source NLS_CHARACTERSET or the target characterset you specified does not define that character. If no action is taken then this data will be 'lost' in the conversion. Every "lossy" character will be then converted to the "default replacement character". What that "default replacement character" is depends on the charactersets, for US7ASCII this is a question mark "?", for xx8ISO8859Px and xx8MSWIN125x charactersets this is a inverted question mark "?".
Please note that every lossy is converted to the same "default replacement character" hence once you have done a conversion that resulted in lossy there is no way to "recover" the original data. If you have for example an US7ASCII database that contains the string "é? ?" (= 3 characters who are not defined in US7ASCII) and you exp/imp this into a WE8MSWIN1252 database then this will become "???" in the WE8MSWIN1252 database. Seen you have 3 times the same character for each "source" character there is no way after the conversion to debug what was supposed to be there. You will need to go back to the source database for this. This is not a bug, simply how charactersets work and standard behavior.
So this is an important column to watch, because this data needs to be addressed to preserve the content and prevent data loss.





10g以后使用 csalter.plb修改字符集 ,而非 8i/9i的 直接 ALTER DATABASE CHARACTER SET





[oracle@vrh8 ~]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Apr 19 10:39:03 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SQL> conn / as sysdba
Connected.


SQL> -- Make sure the CLUSTER_DATABASE parameter is set
SQL> -- to false or it is not set at all.
SQL> -- If you are using RAC you will need to start the database in single instance
SQL> -- with CLUSTER_DATABASE = FALSE
SQL> sho parameter CLUSTER_DATABASE

NAME                                 TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
cluster_database                     boolean
FALSE
cluster_database_instances           integer
1
SQL> -- if you are using spfile note the
SQL> sho parameter job_queue_processes
sho parameter aq_tm_processes

NAME                                 TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
job_queue_processes                  integer
10
SQL> -- (this is Bug 6005344 fixed in 11g )

NAME                                 TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
aq_tm_processes                      integer
0
SQL> SQL> -- then do



SQL> shutdown
startup restrict
SPOOL Nswitch.log

-- do this alter system or you might run into "ORA-22839: Direct updates on SYS_NC columns are disallowed"
-- This is only needed in 11.1.0.6, fixed in 11.1.0.7, not applicable to 10.2 or lower
-- ALTER SYSTEM SET EVENTS '22838 TRACE NAME CONTEXT LEVEL 1,FOREVER';

-- then run Csalter.plb
@?/rdbms/admin/csalter.plb
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> ORACLE instance started.

Total System Global Area 1224736768 bytes
Fixed Size                  2020384 bytes
Variable Size             318770144 bytes
Database Buffers          889192448 bytes
Redo Buffers               14753792 bytes
Database mounted.
Database opened.
SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL>
0 rows created.


Function created.


Function created.


Procedure created.

This script will update the content of the Oracle Data Dictionary.
Please ensure you have a full backup before initiating this procedure.
Would you like to proceed (Y/N)?y
old   6:     if (UPPER('&conf') <> 'Y') then
new   6:     if (UPPER('y') <> 'Y') then


Checking data validility...
begin converting system objects

PL/SQL procedure successfully completed.

Alter the database character set...
CSALTER operation completed, please restart database

PL/SQL procedure successfully completed.


0 rows deleted.


Function dropped.


Function dropped.


Procedure dropped.






字符集成功从 ZHS16GBK 转换为 ZHS32GB18030



SQL> SQL> SQL> SQL> select value from NLS_DATABASE_PARAMETERS where parameter='NLS_CHARACTERSET';

VALUE
--------------------------------------------------------------------------------
ZHS32GB18030










SQL> select  * From maclean;

T1
--------------------------------------------------------------------------------

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-15 12:43 , Processed in 0.061526 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569