ORA-12537
[root@ocp ~]# oerr ora 12537
12537, 00000, "TNS:connection closed"
// *Cause: "End of file" condition has been reached; partner has disconnected.
// *Action: None needed; this is an information message.

1. ORA-12537 连接被关闭错误有着较为触发条件，包括：
2. 数据库处于shutdown过程中触发
3. 一个实际发生的连接超时，例如客户端网络访问服务器所在ip确实发生了超时
4. 防火墙导致的连接失败
5. listener.ora或者sqlnet.ora配置文件出了问题
6. windows上的tns客户端的路径配置过长 Connecting From a Client Application With Long PATH / Target String Fails With ORA-12537 (Doc ID 263489.1)
7. 还有一种可能是例如在unix/linux上 oracle 2进制文件或$ORACLE_HOME目录的权限不正确

检查 oracle和grid用户的oracle 2进制文件权限

su - oracle

ls -l $ORACLE_HOME/bin/oracle

su - grid

ls -l $ORACLE_HOME/bin/oracle

 

[oracle@ocp ~]$ ls -l $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle oinstall 239626683 Aug 7 2015 /s01/oracle/app/oracle/product/11.2.0/dbhome_1/bin/oracle

确保其权限为  -rwsr-s--x

如不是 则修改 ：

[oracle@ocp ~]$ chmod 6751 $ORACLE_HOME/bin/oracle

[oracle@ocp ~]$ ls -l $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle oinstall 239626683 Aug 7 2015 /s01/oracle/app/oracle/product/11.2.0/dbhome_1/bin/oracle

 

[oracle@ocp ~]$ ls -ld $ORACLE_HOME
drwxr-xr-x 75 oracle oinstall 4096 Aug 7 2015 /s01/oracle/app/oracle/product/11.2.0/dbhome_1

 

ORACLE_HOME权限应为755，如不是则修改

 

chmod 755 $ORACLE_HOME

 

适用于:

Oracle Database – Enterprise Edition – 版本 12.1.0.2 和更高版本
Oracle Database Cloud Schema Service – 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine – 版本 N/A 和更高版本
Oracle Database Exadata Express Cloud Service – 版本 N/A 和更高版本
Oracle Cloud Infrastructure – Database Service – 版本 N/A 和更高版本
本文档所含信息适用于所有平台

用途

理解 12.1.0.2 开始，脑裂问题发生后，节点保留策略。

详细信息

在 11.2 及早期版本，在脑裂发生时，节点号小的会保留下来。然而从 12.1.0.2 开始，引入节点权重的概念。从 12.1.0.2 开始，解决脑裂时，权重高的节点将会存活下来。

适用于:

Oracle Database Cloud Schema Service – 版本 N/A 和更高版本
Oracle Database Exadata Express Cloud Service – 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine – 版本 N/A 和更高版本
Oracle Cloud Infrastructure – Database Service – 版本 N/A 和更高版本
Oracle Database Backup Service – 版本 N/A 和更高版本
本文档所含信息适用于所有平台

用途

本文档提供了关于自动维护任务或 AUTOTASK 作业的更多信息，这些作业是 11g 系统自动生成的新设置。

本文档介绍了 10g 和 11g 之间关于维护任务的一些主要差异。

适用范围

本文档与 Oracle 11g 相关，目标受众是 Oracle DBA 和支持分析人员。

详细信息

Introduction

Oracle 11g 数据库有三个预定义自动维护任务：

Automatic Optimizer Statistics Collection（自动优化器统计信息收集）

收集数据库中所有无统计信息或仅有过时统计信息的 Schema 对象的 Optimizer（优化器）统计信息。SQL query optimizer（SQL 查询优化器）使用此任务收集的统计信息提高 SQL 执行的性能。

Automatic Segment Advisor（自动段指导）

识别有可用回收空间的段，并提出如何消除这些段中的碎片的建议。您也可以手动运行 Segment Advisor 获取更多最新建议，或获取 Automatic Segment Advisor 没有检查到的那些有可能做空间回收的段的建议。

Automatic SQL Tuning Advisor（自动 SQL 优化指导）

检查高负载 SQL 语句的性能，并提出如何优化这些语句的建议。您可以配置此指导，自动应用建议的SQL profile。

Note 755838.1 – New 11g Default Jobs

实施

它们在 Oracle10g 中为独立作业，且在 DBA_SCHEDULER_JOBS.JOB_NAME 中可见。

这在 Oracle11g 中有所更改。相关视图为 DBA_AUTOTASK_WINDOW_CLIENTS。
现在，这些作业只有当被真正执行时，才在 DBA_SCHEDULER_JOBS 中可见，且名称为系统生成的名称。

SQL> desc DBA_AUTOTASK_WINDOW_CLIENTS
Name                                      Null?    Type
—————————————– ——– —————————-
WINDOW_NAME                               NOT NULL VARCHAR2(30)
WINDOW_NEXT_TIME                                   TIMESTAMP(6) WITH TIME ZONE
WINDOW_ACTIVE                                      VARCHAR2(5)
AUTOTASK_STATUS                                    VARCHAR2(8)
OPTIMIZER_STATS                                    VARCHAR2(8)
SEGMENT_ADVISOR                                    VARCHAR2(8)
SQL_TUNE_ADVISOR                                   VARCHAR2(8)
HEALTH_MONITOR                                     VARCHAR2(8)

select * from DBA_AUTOTASK_WINDOW_CLIENTS;

WINDOW_NAME
——————————
WINDOW_NEXT_TIME
—————————————————————————
WINDO AUTOTASK OPTIMIZE SEGMENT_ SQL_TUNE HEALTH_M
—– ——– ——– ——– ——– ——–
MONDAY_WINDOW
08-DEC-08 10.00.00.000000 PM EUROPE/VIENNA
FALSE ENABLED ENABLED ENABLED ENABLED DISABLED

…

SUNDAY_WINDOW
07-DEC-08 06.00.00.000000 AM EUROPE/VIENNA
FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
7 rows selected.

要启用或禁用所有窗口的所有自动维护任务，在不使用任何参数的情况下调用 ENABLE 或 DISABLE 程序。

要禁用特定维护任务，使用 DISABLE 程序，如下所示：

要再次启用该特定维护任务，使用 ENABLE 程序，如下所示：

client_name 参数使用的任务名称列在 DBA_AUTOTASK_CLIENT 数据库字典视图中。

另一个差异是预定义调度程序窗口：

•   Oracle10g : WEEKNIGHT_WINDOW and WEEKEND_WINDOW
•   Oracle11g : MONDAY_WINDOW …. SUNDAY_WINDOW.

为了向下兼容，WEEKNIGHT_WINDOW 和 WEEKEND_WINDOW 仍然存在。

窗口打开持续的时间在 11g 中有所更改。星期一到星期五从晚上 10 点到凌晨 2 点，星期六到星期日从上午 6 点到凌晨 2 点。

适用于:

Oracle Database – Enterprise Edition – 版本 8.1.7.4 和更高版本
Oracle Database – Standard Edition – 版本 8.1.7.4 和更高版本
本文档所含信息适用于所有平台

用途

本文章概述了更改数据库字符集或在具有不同 NLS_CHARACTERSET 的数据库之间导出/导入前进行检查的方法。

当前的 NLS_CHARACTERSET 在 NLS_DATABASE_PARAMETERS 中可以看到。

NLS_CHARACTERSET（“字符集”）定义了“普通”的 CHAR, VARCHAR2, LONG 以及 CLOB 字段的编码。

NLS_NCHAR_CHARACTERSET（“国家字符集”）定义了 NCHAR, NVARCHAR2 以及 NCLOB 字段的编码。从 9i 以后都是 Unicode 编码。如果没有使用 NCHAR, NVARCHAR2 以及 NCLOB 字段，那么 NLS_NCHAR_CHARACTERSET 的设置不会被使用或者说不相关。详见 Note 276914.1 The National Character Set in Oracle 9i , 10g and 11g

适用范围

尝试更改 NLS_CHARACTERSET 的所有用户。

详细信息

A) 数据库字符集 (NLS_CHARACTERSET)

Oracle 数据库的 NLS_CHARACTERSET 定义了数据库中哪些字符可以存储在 CHAR、VARCHAR2、LONG 和 CLOB 数据类型中。字符集不定义语言，而是定义字符的特定范围。任何语言，只要它使用包含在该字符集中的字符，即可存储在数据库中。

如果您准备修改数据库的字符集，并且当前使用的某些字符在新的字符集中没有定义，或者当前字符集的设置是不正确的，那么在字符集修改之后就可能发生数据丢失。
在更改字符集前，应始终使用 Character Set Scanner (Csscan) 检查是否存在这种情况。
使用导出/导入操作或 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) 选择新数据库字符集

对于大多数客户，Unicode 字符集 (AL32UTF8) 是最好的选择。
使用AL32UTF8字符集的数据库,你可以存储/查询世界上所有的语言
请参阅 Note 333489.1 Choosing a database character set means choosing Unicode 以及 Note 1051824.6 What languages are supported in an Unicode (UTF8/AL32UTF8) database?

需要注意的是，在选择 Unicode(AL32UTF8) 数据库前，您需要确认应用程序是否支持。这个不是 Oracle 技术支持能检查或确认的。

请检查对应的应用程序文档，或咨询应用程序提供商及支持团队，以确认应用程序同 AL32UTF8 或 UTF8 的认证关系。我们强烈建议这么做。

不需要特意安装Unicode或其它字符集,因为所有Oracle的字符集包括Unicode,都已经默认安装了.

对于非 Unicode 字符集，最佳选择是 xx8MSWIN125x 字符集，即使数据库自身在 Unix 平台上运行。原因很简单：大多数客户端都是基于 Windows 系统的，因此最适合数据库的非 Unicode 字符集是可以存储这些客户端能够识别的所有字符的字符集，即 xx8MSWIN125x 字符集：

EE8MSWIN1250 , CL8MSWIN1251, WE8MSWIN1252, EL8MSWIN1253 ,TR8MSWIN1254, IW8MSWIN1255, AR8MSWIN1256, BLT8MSWIN1257。

对于亚洲语言推荐的字符集是 VN8MSWIN1258, TH8TISASCII, JA16SJIS , KO16MSWIN949, ZHS16GBK, ZHT16MSWIN950 , ZHT16HKSCS31。

详细讨论，请参阅 Note 264294.1 Choosing from WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 as db character set.

如果想知道哪些语言可以存储在大多数常用字符集中，请参阅 Note 62421.1 Which Character Set Supports Which Language

如果想知道特定字符集中包含哪些字符，请参阅 Note 282336.1 Charts of most current mono-byte Character sets
或者使用 Locale Builder 打开 Oracle 字符集定义，请参阅 Note 223706.1 Using Locale Builder to view the definition of character sets

这里有一个非常优秀的外部资源： http://www.eki.ee/letter/. 在该网站中选择某个语言后，它将显示包含此语言所需的全部字母的所有字符集概览。
请注意，Oracle 不保证该网站中的信息完全正确。

从版本 11g 开始，DBCA 默认提供“推荐”字符集列表用作 NLS_CHARACTERSET，出于上述相同的原因，列表中不包含类似于 WE8ISO8859P1 的字符集。请注意，Oracle仍然对这些字符集提供支持，并且根据需要，也可以使用“非推荐”字符集。有关更多信息，请参阅 Note 306411.1 Character Set Consolidation for Oracle Database 11g以及如下文档的”Locale Data” , “Character Sets”部分
11.2. : http://docs.oracle.com/cd/E11882_01/server.112/e10729/applocaledata.htm#NLSPG585 
12.1: http://docs.oracle.com/database/121/NLSPG/applocaledata.htm#NLSPG584 

如果在 11g 中必需使用 DBCA 中的一个“非推荐”字符集（如 US7ASCII 或 WE8ISO8859P1）创建数据库，则在 11g DBCA 的步骤 9（共 11 个）”Character Sets”选项卡中，钩掉”show recommended character sets only”，然后选择”Choose from the list of character sets”。

在 12c 的 DBCA 中，选择” create a database”，在第2步中选择”advanced mode”，第10步在”Character Sets”选项卡中，钩掉”show recommended character sets only”，然后选择”Choose from the list of character sets”，之后就可以选择不推荐的字符集（比如 US7ASCII 或 WE8ISO8859P1）作为数据库的字符集（NLS_CHARACTERSET）。

关于 ORA-xxxx 错误的语言问题,请参照文档 Note 985974.1 Changing the Language of RDBMS (Error) Messages

C) 在8i, 9i, 10g 和 11g 中更改数据库字符集。

请注意，如果一开始就更改数据库字符集，很有可能*无法*解决显示问题。
因此，请先检查是否可以使用 SQLdeveloper 存储/检索数据，这款工具是无需进行 NLS 配置的“好客户端”。
note 1628060.1 How to diagnose losing characters , getting “funny” output when inserting or selecting other than A-Z,a-z data ( = non English data like Chinese, Russian, Hebrew , insert any language here to the list that is not English) CHAR, VARCHAR2, LONG or CLOB

C1) 运行 Oracle Application (EBS) 或 PeopleSoft 系统的 数据库字符集转换

请参见文档: Note 124721.1 Migrating an Applications Installation to a New Character Set.

这是唯一的 Oracle applications 提供支持的方法。如果您有任何疑问请创建一个 Oracle Applications 的 SR 以寻求协助。

对于一个Oracle PeopleSoft的数据库，请参照文档note 703689.1 Converting PeopleSoft Systems to Unicode Databases
如果您有任何疑问请创建一个 Oracle PeopleSoft 的 SR 以寻求协助。

C2) 在8i, 9i, 10g 和 11g 中使用“export/import”操作（在 10g 及更高版本中使用Datapump操作）。

您只需导出当前的数据库，然后使用新字符集新建一个数据库，并将数据导入到该数据库中。Export/import (原来的 exp/imp tools 或者 expdp/impdp) 适用于原字符集中的字符在新字符集中都有定义（但它们可能有不同的编码）。

需要注意的是您要存储的字符仍需在原字符集中有正确的定义。

很多时候这个条件都是无法满足的，所以需要通过对源数据库使用 csscan检测这些错误，因此在使用 exp/imp 时，我们建议始终先用 Csscan 检测是否存在问题。

数据丢失（字符在 export/import 之后变成 ? 或者 ¿ ）在 export/import 的过程中是不会报错的。

请务必参阅 C3) 或尽早使用 csscan 来避免问题的发生。

如果 csscan 报告有可能发生数据丢失，那么不要使用 export/import

如果要在现有数据库之间导出/导入特定的用户或表，且其中一个数据库是 UTF8 或 AL32UTF8 数据库，则请参阅：Note 1297961.1 ORA-01401 / ORA-12899 While Importing Data In An AL32UTF8 / UTF8 (Unicode) Or Other Multibyte NLS_CHARACTERSET Database.

注意对于 Transportable tablespaces 的局限: note 297396.1  The Character Set Check Performed When Plugging In a Transportable Tablespace 或者文档 http://docs.oracle.com/cd/E11882_01/server.112/e25494/tspaces.htm#i1007233

C3) 组合使用 ALTER DATABASE CHARACTER SET（8i、9i）/ CSALTER（10g 和 11g）与 “export/import” 操作

在大多数情况下 Csscan 会指出有些数据需要转换为新的字符集（“Convertible”数据），而方法 c2 又会占用太多时间。
在这些情况下，通常可以混合使用 export/import 和 ALTER DATABASE CHARACTER SET（8i、9i）/ CSALTER（10g 和 11g）：

a) 导出 Csscan 列出的表中的“Convertible”数据（即代码在当前字符集和新字符集之间会发生转换的字符）
b) truncate 或 drop 掉这些表。
c) 再次运行 csscan，以确保所有数据现已准备好直接移到新字符集中，如果确实已准备就绪，则使用 ALTER DATABASE CHARACTERSET（8i、9i）/CSALTER（10g 和 11g）命令更改数据库的字符集。
d)由于字符集现已更改，我们只需导入在步骤 (a) 导出的数据。导入操作将转换该数据，并使用该新字符集的正确字符代码进行存储。

在 8i、9i、10g 和 11g 中的 8 位字符集之间执行字符集转换的分步指南 。

下面这些文章会指导您完成一些常用的转换操作，其中介绍了如何将上述“组合方法”（如果需要）付诸实践以及如何进行额外的校验：

从 US7ASCII 更改为 WE8MSWIN1252 或从其他 xxIOS8859Pxx 更改为 xx8MSWIN12xx 字符集
Note 555823.1 Changing from US7ASCII or WE8ISO8859P1 to WE8MSWIN1252 in 8i, 9i, 10g and 11g
Note 1213683.1 Changing from US7ASCII or WE8ISO8859P1 or IW8ISO8859P8 to IW8MSWIN1255 in 8i, 9i, 10g and 11g
Note 260022.1 Changing From US7ASCII or WE8ISO8859P1 or AR8ISO8859P6 to AR8MSWIN1256 in 8i, 9i, 10g and 11g
Note 261871.1 Changing EL8ISO8859P7 to EL8MSWIN1253 in 8i, 9i, 10g and 11g
Note 263119.1 Changing EE8ISO8859P2 to EE8MSWIN1250 in 8i, 9i, 10g and 11g
Note 266309.1 Changing WE8ISO8859P9 to WE8ISO8859P1/WE8MSWIN1252 in 8i, 9i, 10g and 11g
Note 246008.1 Changing WE8ISO8859P15 to WE8MSWIN1252 in 8i, 9i, 10g and 11g

其他组合：

Note 1104893.1 Changing US7ASCII TO WE8ISO8859P1 in 8i, 9i, 10g and 11g
Note 1963942.1 Changing WE8DEC to WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 in 8i, 9i, 10g and 11g
Note 257722.1 Changing WE8ISO8859P1 to WE8ISO8859P15 in 8i, 9i, 10g and 11g
Note 261639.1 Changing WE8MSWIN1252 to WE8ISO8859P15 in 8i, 9i, 10g and 11g
Note 273281.1 Changing WE8ISO8859P15 TO WE8ISO8859P1 in 8i, 9i, 10g and 11g

如果要转换成  ZHS16GBK, ZHT16MSWIN950, ZHT16HKSCS, ZHT16HKSCS31,KO16MSWIN949, JA16SJIS 这样的字符集，步骤同文档 Note:260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) 是一样的。

我们强烈推荐使用 AL32UTF8 做数据库的 NLS_CHARACTERSET。使用上边的字符集没有什么额外的价值。

基本上 AL32UTF8 是大势所趋，AL32UTF8 支持所有其它字符集定义的字符。

C4) 在 8i、9i、10g 和 11g 中将字符集转换为 Unicode (UTF8/AL32UTF8) 的分步指南（包括导出/导入操作）

转换到 Unicode ( AL32UTF8 or UTF8 NLS_CHARACTERSET) 可以：

根据文档 Note 260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode), 里边也包括了如何使用 csscan 的步骤。

• 或者使用部分 export/import 加 csscan / csalter 将现有的数据库转换掉。
• 或者使用全库 export/import 迁移到一个新的 AL32UTF8 数据库。

或者使用 DMU 工具将现有数据库转换成 AL32UTF8 ，参见 Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool
DMU 支持11.2.0.3 及之后版本的数据库以及某些选定的旧版本/平台的组合。
建议在使用 DMU 转换前阅读文档 Note 1272374.1 以及 note 1522722.1 Known Issues With The Database Migration Assistant for Unicode (DMU) Tool version 1.2 (current version)

究竟使用 csscan 加 csalter及部分 export/import，还是使用 DMU 工具，或者使用全库 export/import 我们没有特别的推荐。

一般来说 DMU 工具

• 对用户更友好
• 在转换一个已存在的数据库时，转换过程不需要 export/import
• 如果有很多数据需要修正那么它更简单(通常发生在 US7ASCII 或 WE8ISO8895P1 的数据库上)
• 如果需要操作的数据量比较少那么它比csscan/csalter/部分 export/import 快。

一般来说 csscan 加 csalter 以及部分 export/import ( = 按Note 260192.1的所有步骤操作)

• 喜欢用脚本的人更倾向于使用
• 过去就知道或者使用过
• 如果操作的数据量比较打那么它比 DMU 工具快。

一般来说如果迁移到新的机器那么通常先使用csscan转换，之后使用全库 export/import。 (检查文档 Note 260192.1 的前六步和第12步)

• 导入一个新的AL32UTF8数据库 （如果是迁移到新的机器上）
• 导入到同一台机器的另一个新建的AL32UTF8数据库中 (这样的步骤最少，如果可以容忍停机时间的话)

这三种方式最终的成果是一样的，都是转换成 AL32UTF8。
我们也无法知道究竟哪种方法更快，只能通过测试才能知道。

最好先阅读 Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications，特别是 “c) the Client side”, 关于 NLS_LANG 通常有很多误解。

将 NLS_CHARACTERSET 从 UTF8 改为 AL32UTF8 (或者从 AL32UTF8 到 UTF8) 可以通过 Note 260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) in 8i, 9i, 10g and 11g. 来实现。

C5) Physical / Logical Standby 数据库如何操作?

如果配置中涉及到 Logical Standby 数据库，那么在修改了主库字符集后 Logcial Standby 数据库必须重建。其它修改 logical standby 数据库的字符集的方式我们都不支持。

Logical standby 数据库需要同主库有相同的 NLS_CHARACTERSET，而且如果说先修改 Logical Standby 的字符集，之后的 SQL apply 也不会成功。

对于版本低于11.1.0.7的 Physical Standy 数据库，备库也需要重建。

对于11.1.0.7 之后的 Physical Standbys 不需要重建, 详见 Note 1124165.1 Changing Primary Database Character Set without Recreating Data Guard Physical Standbys

C6) 如何将数据库从 AL32UTF8/UTF8 改回另外的字符集?

如果您已经有了一个 AL32UTF8 或者 UTF8 但是后来发现应用程序不支持 AL32UTF8 或者 UTF8，那么您可以通过  note 1283764.1 Changing the NLS_CHARACTERSET From AL32UTF8 / UTF8 (Unicode) to another NLS_CHARACTERSET in 8i, 9i, 10g and 11g 将 NLS_CHARACTERSET 改为另外一个。
注意在很多情况下这会造成数据丢失。

D) 在 Oracle 12c 中将数据库字符集修改为 Unicode(UTF8/AL32UTF8)

对于将已经存在的数据库字符集迁移至AL32UTF8 (以及已经废弃的 UTF8)，在 12c 中我们提供了工具 Database Migration Assistant for Unicode (DMU)。
DMU 工具是唯一的下一代的用来将字符集迁移至 Unicode 的工具。
DMU 提供的交互界面能极大的简化迁移的步骤并且不需要 DBA 有太多的字符集移植经验，同时它还自动完成了很多移植过程需要的操作。
详见文档 Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool.
从 Oracle database 12c开始，迁移 NLS_CHARACTERSET 只能使用工具DMU：Note 1418321.1 CSSCAN and CSALTER To Be Desupported after DB 11.2.

E) 12c Multitenant Container Databases (CDB) 和 Pluggable Databases (PDB) 中字符集的限制:

如何把一个字符集不同的pdb插入到CDB中,请参照请参照
note 1968706.1 ORA-65116/65119: incompatible database/national character set ( Character set mismatch: PDB character set CDB character set )
或者

参见如下文档 Oracle® Database Globalization Support Guide 12c Release 1 (12.1) , 2 Choosing a Character Set , Choosing a Database Character Set for a Multitenant Container Database
http://docs.oracle.com/cd/E16655_01/server.121/e17750/ch2charset.htm#NLSPG1035

DMU工具是唯一一个可以用来把pdb从非Unicode转换成Unicode的工具,参照文档note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool / 13) How to convert non-Unicode PDB’s to Unicode PDB’s?

F) 其他阅读材料

更改 Oracle Application 数据库的字符集时，还有一些其他注意事项，有关这些事项的完整概述，请参阅以下文章：Note 124721.1 Migrating an Applications Installation to a New Character Set

客户端配置：

Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications / point “c) the Client side”,
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.

有关调试指南的详细信息，请参阅 Note 788931.1 Troubleshooting RDBMS (client and server) NLS Problems (Charactersets, sorts, dates, ..)

Note that NLS_LANGUAGE and NLS_TERRITORY have nothing to do with the ability to *store* characters in a database.
A database using WE8MSWIN1252 NLS_CHARACTERSET and JAPANESE JAPAN as NLS_LANGUAGE and NLS_TERRITORY will *not* allow you to store Japanese as WE8MSWIN1252 doesn’t define Japanese characters.
A database using AL32UTF8 NLS_CHARACTERSET and AMERICAN AMERICA as NLS_LANGUAGE and NLS_TERRITORY *will* allow you to store Japanese (or any other language in the world for that matter).

适用于:

Oracle Database – Enterprise Edition – 版本 12.1.0.1 和更高版本
Oracle Database Cloud Schema Service – 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine – 版本 N/A 和更高版本
Oracle Database Exadata Express Cloud Service – 版本 N/A 和更高版本
Oracle Cloud Infrastructure – Database Service – 版本 N/A 和更高版本
本文档所含信息适用于所有平台

用途

概述 Oracle 12c 新特性，如何使用 RMAN 备份和恢复可插拔数据库。

适用范围

数据库管理员管理大量的数据库，通过 RMAN 备份。他们期望实施一个容器数据库进行统一备份，容器数据库包含一个或者多个可插拔数据库。需要掌握 RMAN 知识。

详细信息

什么是容器数据库？

12c 数据库可以是容器数据库或非容器数据库，本文将非容器数据库简称为 non-CDB，容器数据库简称为CDB。

12c 之前的数据库库只能作为非容器数据库即 non-CDBs。

一个容器数据库可以包含 0 个，1 个或多个用户创建可插拔数据库。可插拔数据库简称为 PDB。

容器数据库包括：

• 一个根容器（即：CDB$ROOT）有 SYSTEM，SYSAUX，UNDO 和 TEMP 表空间，以及控制文件和在线日志文件。
• 一个种子容器（即：PDB$SEED）有 SYSTEM，SYSAUX，TEMP，EXAMPLE 表空间，种子容器作为创建可插拔数据库（PDB）的模板。

什么是可插拔数据库？

可插拔数据库（PDB）就是一个用户创建的容器，存放用户应用系统的数据和代码。例如：人力应用系统，薪酬管理系统等。
可插拔数据库包括：

• SYSTEM，SYSAUX，TEMP 表空间
• 任意多用户创建的表空间
• PDB 向容器数据库的 UNDO 表空间，控制文件和在线日志文件写信息

当可插拔数据库往容器数据库的 UNDO 表空间和在线日志文件写信息时，会注释每个 UNDO 和 REDO 属于哪个可插拔数据库。

RMAN 备份可插拔数据库

执行 RMAN 备份的用户必须要有 SYSDBA 或新权限 SYSBACKUP

RMAN 可从根容器端运行，如：rman target sys/<pw>@t12ccdb

rman target /

或者从可插拔数据库端运行，如：rman target sys/<pw>@t12cpdb1

当 RMAN 连接的数据库是可插拔数据库，RMAN 命令仅作用于被连的可插拔数据库。

当 RMAN 连接的数据库是根容器数据库，RMAN 命令默认作用于容器中的所有文件，除非使用 PDB 名称进行了特别限制。

RMAN 命令 REPORT SCHEMA 能显示容器数据库的所有数据文件。
下面例子显示可插拔数据库 T12cPDB1 在容器数据库 T12cCDB 中：

现在只有 REPORT SCHEMA 命令能很容易的显示容器数据库中数据文件属于哪个可插拔数据库。
假如连接的数据库是可插拔数据库，仅显示它自己的数据文件：

1. 完整容器数据库备份

备份全部数据文件，包括根容器数据库文件，种子数据库文件，以及所有可插拔数据库文件：

2. 容器数据库部分数据备份

下面例子显示仅备份可插拔数据库 T12CPDB1：

当备份可插拔数据库时，不需要像上述例子使用 TAG 参数指定可插拔数据库的名字。因为 RMAN LIST BACKUP 命令自动会显示 RMAN 备份数据属于哪个可插拔数据库。

因为在 FRA 会将 GUID 信息显示在文件路径名称上，在这种情况下，使用下面查询识别可插拔数据库名称和 GUID 的对应关系。

下面例子，显示了可插拔数据库 T12CPDB1 对应的 GUID 是 C4B71645EF062616E0437108DC0A91E4。

登录容器数据库：

3. 部分可插拔数据库备份

3a. 连接到根容器数据库，仅备份可插拔数据库 T12CPDB1 的 system 和 sysaux 表空间

3b. 仅备份可插拔数据库的 SYSTEM 表空间和根容器数据库的 SYSAUX 表空间

当连接到根容器数据库执行备份时，如果没有指定可插拔数据库前缀，默认备份数据文件是根容器数据库

3c. 容器数据库中每个文件号都是唯一的，可以连接到根容器数据库，不指定容器前缀，使用文件号进行备份。

下面例子显示如何连接到根容器数据库，不用指定容器数据库前缀，仅备份 CDB$ROOT 的 3 号数据文件，和 T12CPDB1 的 20 号数据文件

RMAN 可插拔数据库的恢复

1. 可插拔数据库 T12cPDB1 system 数据文件丢失

这种情况下，容器数据库和其它可插拔数据库不受影响，可正常使用，仅 T12CPDB1 可插拔数据库不可用。
必须从根容器数据库进行恢复。

可插拔数据库的system数据文件丢失可能造成和容器数据库的system数据文件丢失一样严重后果，导致整个容器数据库宕掉，所有可插拔数据库都成为不可用

在这种情况下，需要将容器数据库放在 mount 状态下，恢复可插拔数据库的 system 数据文件。

未来的版本将会有所改善，可插拔数据库 system 数据文件的丢失不影响容器数据库或其他可插拔数据运行。

2. 可插拔数据库的非系统数据文件丢失，比如USER表空间的10号数据文件丢失

根据实际情况，丢失的数据文件可能已经是 offline 状态，如果没有，必须先 offline：

3. 可插拔数据库的整个表空间的数据文件都丢失

某个表空间丢失，但是可插拔数据库 T12CPDB1 还处于打开状态。

4: 可插拔数据库的所有数据文件都丢失

注：

丢失了可插拔数据库并不同于删除了可插拔数据库。

-丢失了可插拔数据库是指因为一些意外情况下的数据库以及文件的误删除或者损坏， 但是它的metadata数据还是存在的。在这种metadata还存在的情况下，从备份中恢复出来是可行的。

-如果是删除了可插拔数据库，这样同样会把metadata从repository中删除。这种情况下做restore就会遇到错误：

RMAN-06813: could not translate pluggable database PDB1

另外，如果我们对单个可插拔数据库备份进行备份，这对恢复不同服务器中的单个可插拔数据库或执行时间点恢复是没有用处的。

********我们必须拥有root和可插拔数据库的备份**************

适用于:

Oracle Database – Enterprise Edition – 版本 10.1.0.2 和更高版本
Oracle Net Services – 版本 10.2.0.5 到 10.2.0.5 [发行版 10.2]
本文档所含信息适用于所有平台

目标

本文概括了如何通过 DBMS_WORKLOAD_REPOSITORY 提供的脚本和功能来创建AWR报告和基线。本文介绍了如何生成各种类型的 AWR 报告和手工创建 AWR 快照，也介绍了一些关于 AWR 基线的内容。

解决方案

AWR 是被 sys 用户拥有的一个存放系统性能指标的集合。
它存放于 SYSAUX 表空间. 默认情况下每60分钟产生一个 AWR 快照并且保留8天, 这样能确保捕获一周的性能指标数据（注意在 10g 中保留期是7天）。

AWR 报告输出一系列指标在两个快照之间的差值，用于研究数据库性能以及其他问题。

生成一个最基本的 AWR 报告

如果您拥有了相应的 AWR License 授权，那么您可以通过如下脚本来选择两个您想采用的快照，生成一个 AWR 报告：

基于不同的原因，通常可以采用默认的设置来产生 AWR 快照，但如果需要更精确的报告，那么可能需要采用更短的比如10-15分钟的快照。

在生成 AWR 报告的过程中，会要求提供产生的 AWR 报告格式（text 或者 html）以及报告的名称。

生成多种类型的 AWR 报告

可以通过不同脚本来产生不同类型的 AWR 用于满足不同的需求，所有的 AWR 报告都可以是 HTML 或者 TXT 格式：

• awrrpt.sql 
  展示一段时间范围两个快照之间的数据库性能指标。
• awrrpti.sql 
  展示一段时间范围两个快照之间的特定数据库和特定实例的性能指标。
• awrsqrpt.sql
  展示特定 SQL 在一段时间范围两个快照之间的性能指标，运行这个脚本来检查和诊断一个特定 SQL 的性能问题。
• awrsqrpi.sql
  展示特定 SQL 在特定数据库和特定实例的一段时间范围内两个快照之间的性能指标。
• awrddrpt.sql
  用于比较两个指定的时间段之间数据库详细性能指标和配置情况。
• awrddrpi.sql 
  用于在特定的数据库和特定实例上，比较两个指定的时间段之间的数据库详细性能指标和配置情况。

AWR 快照

如何修改 AWR 快照的设置：

BEGIN 
  DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings( 
    retention => 43200,        -- 单位是分钟 (43200 = 30 Days)。
                               -- 设置成 NULL 代表保持原来设置。
    interval  => 30);          -- 单位是分钟, 设置成 NULL 代表保持原来设置。
END; 
/

手工创建一个 AWR 快照：

BEGIN 
  DBMS_WORKLOAD_REPOSITORY.create_snapshot(); 
END; 
/

按照范围删除 AWR 快照：

BEGIN 
  DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(
low_snap_id=>40, 
High_snap_id=>80); 
END; 
/

AWR 基线

生成 AWR 基线：

BEGIN 
  DBMS_WORKLOAD_REPOSITORY.create_baseline ( 
    start_snap_id => 10,  
    end_snap_id   => 100, 
    baseline_name => 'AWR First baseline'); 
END; 
/

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
start_time => to_date('&start_date_time','&start_date_time_format'),
end_time => to_date('&end_date_time','&end_date_time_format'),
baseline_name => 'MORNING',
template_name => 'MORNING',
expiration => NULL ) ;
END;
/

“expiration => NULL” 代表这个基线将被永远保留。

删除 AWR 基线：

BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'AWR First baseline');
END;
/

您也可以删除一个在其他数据库或者旧数据库中创建的 AWR 基线：

BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'peak baseline',cascade => FALSE, dbid => 3310949047);
END;
/

我们也可以基于重复时间周期来制定用于创建和删除 AWR 基线的模板：

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
day_of_week => 'MONDAY',
hour_in_day => 9,
duration => 3,
start_time => to_date('&start_date_time','&start_date_time_format'),
end_time => to_date('&end_date_time','&end_date_time_format'),
baseline_name_prefix => 'MONDAY_MORNING'
template_name => 'MONDAY_MORNING',
expiration => 30 );
END;
/[Insert code here]

这样会在指定的时间’&start_date_time’ 到 ‘&end_date_time’期间的每个周一产生一个 AWR 基线

AWR 相关的视图

如下系统视图与 AWR 相关：

• V$ACTIVE_SESSION_HISTORY – 展示每秒采样的 active session history (ASH)。
• V$METRIC – 展示度量信息。
• V$METRICNAME – 展示每个度量组的度量信息。
• V$METRIC_HISTORY – 展示历史度量信息。
• V$METRICGROUP – 展示所有的度量组。
• DBA_HIST_ACTIVE_SESS_HISTORY – 展示 active session history 的历史信息。
• DBA_HIST_BASELINE – 展示 AWR 基线信息。
• DBA_HIST_DATABASE_INSTANCE – 展示数据库环境信息。
• DBA_HIST_SNAPSHOT – 展示 AWR 快照信息。
• DBA_HIST_SQL_PLAN – 展示 SQL 执行计划信息。
• DBA_HIST_WR_CONTROL – 展示 AWR 设置信息。

自动创建 AWR 报告?

Oracle 没有提供自动产生 AWR 报告的功能，AWR 报告的生成是一个手工过程，但是可以通过调度（比如 UNIX 的 crontab）在脚本（比如一些 UNIX 的 bash 脚本）中调用 dbms_workload_repository.awr_report_text 并且传入awr_report_text 的参数来实现自动产生 AWR 报告的目的。可以在互联网上找到这些脚本，但是 Oracle 官方并没有作为产品的一部分来提供这样的脚本。

使用 AWR 需要的 License

请注意使用 AWR 需要特定的 License，如果没有 AWR License，可以使用 statspack，参见：