Oracle 11.2.0.4 LINUX WINDOWS AIX下载

请注意,如果你有support.oracle.com账号,那么严格从官网下载介质。如果实在没有,那么从互联网上下载介质一定要验证SHA1,避免介质被修改。

 

ORACLE 11.2.0.4 Windows 64bit:

链接:https://pan.baidu.com/s/1DtU0rQxEPryxopotN85Icw
提取码:29rx
复制这段内容后打开百度网盘手机App,操作更方便哦

 

11.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER (Patchset)
p13390677_112040_MSWIN-x86-64_1of7.zip 1.2 GB (1327046969 bytes) 
SHA-256 9C6E1235D1B0EE6C36E3F82FEBDC74160BB9766900579FC7EBBFACECD6E8F4B2 
SHA-1 893475AFA9C6758FB14E8269EF05F6D485445F28 

p13390677_112040_MSWIN-x86-64_2of7.zip 1.1 GB (1152431908 bytes) 
SHA-1 6EE067D16F80061B03CFD63603B3F5E454B6152D 
SHA-256 6343B2EA4F47C4E85FD4DC1B5C2EA0B86294E48FAD90DE1820C3F9DF906675F3 

p13390677_112040_MSWIN-x86-64_3of7.zip 735.0 MB (770723774 bytes) 
SHA-256 EC47CFF4D500BD357982C57D9F84F893293A3DBB79A62FC7AE66E2144BEFFF6C 
SHA-1 AA69BD12E01BECBD249C71F8682D75BB2FA003DB 

p13390677_112040_MSWIN-x86-64_4of7.zip 600.7 MB (629885092 bytes) 
SHA-256 10D708F6C3FA12466486BDBB3B1FB235EEEAF1AAB39B67B86C42648F8F49FB33 
SHA-1 821CD458D76672DD10A3C377196C6CE52CBB1BBF 

p13390677_112040_MSWIN-x86-64_5of7.zip 525.6 MB (551173867 bytes) 
SHA-1 E975AA77E4D79B2A22F0F341CBA97EE696B5ADD1 
SHA-256 25FB15F2031C4C82EC09D001023103A9267BC2D34D0F1731E0EBFCDA0495C72E 

p13390677_112040_MSWIN-x86-64_6of7.zip 484.2 MB (507686306 bytes) 
SHA-1 C899797A782DE2A09EC90C57A1117D3490CEAA65 
SHA-256 4A2EF2B9FB3656009320676B2DDFB13A81777B6F2E70ECCA37606637EF796043 

p13390677_112040_MSWIN-x86-64_7of7.zip 108.3 MB (113590540 bytes) 
SHA-1 DCA23E6583527F7ABC19846D1FD51D56DE4C4111 
SHA-256 4BF2626A281C006331846C174790EF63D744C7A0BAC309CAAB48548596476701 

 

 

ORACLE 11.2.0.4 Linux 64bit:

链接:https://pan.baidu.com/s/1uJt7OrgXU-600U7teZKp-Q
提取码:27ud
复制这段内容后打开百度网盘手机App,操作更方便哦

 

11.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER (Patchset)
p13390677_112040_Linux-x86-64_1of7.zip 1.3 GB (1395582860 bytes) 
SHA-256 0B399A6593804C04B4BD65F61E73575341A49F8A273ACABA0DCDA2DFEC4979E0 
SHA-1 983461D6442B0833630475EC4885278588585651 

p13390677_112040_Linux-x86-64_2of7.zip 1.1 GB (1151304589 bytes) 
SHA-1 2E628D8CAC5D1C6FFF15E728B1F227747BF2DED8 
SHA-256 73E04957EE0BF6F3B3E6CFCF659BDF647800FE52A377FB8521BA7E3105CCC8DD 

p13390677_112040_Linux-x86-64_3of7.zip 1.1 GB (1205251894 bytes) 
SHA-1 8C0CD2D7BB2DD73E965A90CD053828D7A52AE7E7 
SHA-256 09C08AD3E1EE03DB1707F01C6221C7E3E75EC295316D0046CC5D82A65C7B928C 

p13390677_112040_Linux-x86-64_4of7.zip 625.6 MB (656026876 bytes) 
SHA-1 1ACF8F785313D3C5CF631A0077416C22348B9DF8 
SHA-256 88B4A4ABB57F7E94941FE21FA99F8481868BADF2E1E0749522BBA53450F880C2 

p13390677_112040_Linux-x86-64_5of7.zip 571.4 MB (599170344 bytes) 
SHA-256 F9C9D077549EFA10689804B3B07E3EFD56C655A4ABA51EC307114B46B8EAFC5F 
SHA-1 8D68764AB38804A9B9C9E80BF5AE0F3D6C397151 

p13390677_112040_Linux-x86-64_6of7.zip 465.7 MB (488372844 bytes) 
SHA-256 B2E08F605D7A4F8ECE2A15636A65C922933C7EF29F7AD8B8F71B23FE1ECBACA8 
SHA-1 79533E2FF40664A4640616BD559903ED616F2633 

p13390677_112040_Linux-x86-64_7of7.zip 114.0 MB (119521122 bytes) 
SHA-256 1CB47B7C0B437D7D25D497ED49719167A9FB8F97A434E93E4663CFA07590E2BA 
SHA-1 B23A8CED6D47664F20C116ABA9A2C77D65B2DD6D 


ORACLE 11.2.0.4 AIX  64bit:

链接:https://pan.baidu.com/s/1kY9AozQGCctxiVLJUcqYfQ
提取码:2322
复制这段内容后打开百度网盘手机App,操作更方便哦

 

11.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER (Patchset)
p13390677_112040_AIX64-5L_1of7.zip 1.7 GB (1801653734 bytes) 
SHA-256 0F74D947F7B8E7E3B1FB4CCC4CB36506E3D1D2DF68E1526AEB7CCB23798F704F 
SHA-1 6A8A7238A796322C6B6AD584805661BC3C368DD1 

p13390677_112040_AIX64-5L_2of7.zip 1.1 GB (1170882875 bytes) 
SHA-1 AE628A661616887E7BA96A2122FB6C62C9B9B6E0 
SHA-256 BD8AAC4DFAFD84840918CDC655D8328AB96EFE1CEB056F843BC75F11BB7AAEC0 

p13390677_112040_AIX64-5L_3of7.zip 2.0 GB (2127071138 bytes) 
SHA-1 BCEDB9007F768A8701406BFE2465E486AF288D52 
SHA-256 CE95498EB70D264E969C48609E5FD036EFF296994725E35AC8E1458B7C8EE9E0 

p13390677_112040_AIX64-5L_4of7.zip 996.5 MB (1044886145 bytes) 
SHA-256 31DD509123F83D414FF1B299E413EF062E4E6F1B48816156AB78CECAF9EEBC83 
SHA-1 FFD1AE113AD645F7891A9C4EB35BDC4BFCBB0A3A 

p13390677_112040_AIX64-5L_5of7.zip 851.6 MB (892976067 bytes) 
SHA-1 AE89F9F347218A8B5FBEE3BB0279099234E65D1A 
SHA-256 54339444BB29B202AB319AB77F00CBB78DD052D558320139CED9E97EC6ACC0F3 

p13390677_112040_AIX64-5L_6of7.zip 543.3 MB (569688642 bytes) 
SHA-256 E64D165372B17F23F5D756381CAAD3FD057A80EAE0CD786589B91982A6993322 
SHA-1 BA3B3BF26B08ADC7A95B94E4E43044A79113524B 

p13390677_112040_AIX64-5L_7of7.zip 215.4 MB (225860409 bytes) 
SHA-256 5D1364CAB9241B7A71EF286D0E86CAC256878E771E9FDDC8CB1CF0E16FB99EAD 
SHA-1 BA37C387373001DF7F3BDF2725301D45519FC00D 

 

 

 

注意,如果没有特殊要求,没有理由使用32bit版本了!!

 

ORACLE 11.2.0.4 Linux 32bit:

链接:https://pan.baidu.com/s/1IORUFF94mmbbIWnGfsYsng
提取码:aci0
复制这段内容后打开百度网盘手机App,操作更方便哦

11.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER (Patchset)
p13390677_112040_LINUX_1of7.zip 1.3 GB (1380374377 bytes) 
SHA-1 A525E17F3C62659AC11ACB39A20711972B1EC22E 
SHA-256 A9D644CA07D043DEB363DC76D385212090527F72B27A802E2FD2965299CD2FF8 

p13390677_112040_LINUX_2of7.zip 1.1 GB (1142436991 bytes) 
SHA-256 BA1D4CB4C186FF3DC40B682AF5134EA7B6FE252A415B61EEA0C42F820C7223EC 
SHA-1 5B8FCE0253EB4549F149DCB9BB9B2646F8755ECD 

p13390677_112040_LINUX_3of7.zip 814.3 MB (853856456 bytes) 
SHA-256 BE9435F8BE3724D2404EBF37150F6B61B45D23970A11CCF661521F29D503B3CF 
SHA-1 50CF20E8C25F3CA723B94699392262F12E090FB9 

p13390677_112040_LINUX_4of7.zip 613.5 MB (643298224 bytes) 
SHA-256 C4ACE48647B045D831516DEE3805BA1F9A40A50E357D6AE5D8E8D141A91410BF 
SHA-1 7657A2DE446D8F016DDC9CE985948F22A66F61F7 

p13390677_112040_LINUX_5of7.zip 560.2 MB (587370432 bytes) 
SHA-256 5BB47B213C8D239133C8E147A6601C4E0EE45C0D6CAD842042F1168640870FA0 
SHA-1 B2F6DF0624DE740B3684383F3CDE25E4D7741F7C 

p13390677_112040_LINUX_6of7.zip 465.1 MB (487722197 bytes) 
SHA-1 FC8E0AC37CED34F0270D36AB4DFF994E2FB3E4BA 
SHA-256 3BAA0F29DA8E1D1E6D70CE6CD4659CD7E0F60F3ADD0C142FEACE816BD0E5F756 

p13390677_112040_LINUX_7of7.zip 113.3 MB (118788536 bytes) 
SHA-1 8E556FC5A5A624CDBA5EF05A47EC10BE607172E9 
SHA-256 5C99E47D01AE4379A63F9DA7BA5F03BCFEF0BD1F80E0C2D4D4142184BB0060C4 

 

 

ORACLE 11.2.0.4 WINDOWS 32bit:

链接:https://pan.baidu.com/s/1mtVVX7cVfFuYRqD8qjbVng
提取码:b3mj
复制这段内容后打开百度网盘手机App,操作更方便哦

11.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER (Patchset)
p13390677_112040_WINNT_1of6.zip 1.2 GB (1303780058 bytes) 
SHA-256 1F1CBB0FCD230CD4E78162A652B2777430B622EA39DE74AD2D67F8E5046DE5A0 
SHA-1 6A0BEB102E2326DE6C0EEB84818FC89AEA1F6518 

p13390677_112040_WINNT_2of6.zip 1.1 GB (1137477960 bytes) 
SHA-256 D12BD4C070A094154FCBDB34F05A7EC0FA7D45B69F6BC7FF0B2DEFEECE1E0873 
SHA-1 821D0B636D4055138CD9B3D4FCA1BA521EA3009B 

p13390677_112040_WINNT_3of6.zip 578.6 MB (606695219 bytes) 
SHA-1 D47447F5FFA46C524B09A635071D3684DC96DA52 
SHA-256 90AAD65DEBFB36A72EF9F515707A0353E38F4ED0F441AFA795D25D82273DCDFE 

p13390677_112040_WINNT_4of6.zip 504.4 MB (528911211 bytes) 
SHA-256 A36FBB370C3A6718611033FDD048BF1155559A9725AFB8D7D5ADD6265EEE0362 
SHA-1 F5C153542F4322B90A92AC47A4EEB732055E0FEA 

p13390677_112040_WINNT_5of6.zip 475.4 MB (498466574 bytes) 
SHA-1 A6F25F4DC426CED3F53C38E584AC2705FD516138 
SHA-256 36ED3410E296F53656ABA6E0FE4BAB69A8059488B5751F9BFD8D2F7F4BDE10A2 

p13390677_112040_WINNT_6of6.zip 105.0 MB (110100340 bytes) 
SHA-1 0A8046C4970B0AAFBFA9A77905EC81B04021F93A 
SHA-256 06093886948C9F7EA33B4E4A73CB7115EBA5B05E924F3A4C2B44B84C74ECB06D 

 

买不买比特币BITCOIN 这是个问题

 

 

买不买比特币BITCOIN 这是个问题

 

 

 

 

 

12C 中,发生脑裂时,节点保留策略 (Doc ID 2047632.1)

适用于:

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 开始,解决脑裂时,权重高的节点将会存活下来。

2014-11-24 14:25:41.140603 : CSSD:1117321536: clssnmrCheckNodeWeight: node(1) has weight stamp(0), pebble(0)
2014-11-24 14:25:41.140609 : CSSD:1117321536: clssnmrCheckNodeWeight: node(2) has weight stamp(311972654), pebble(3)
2014-11-24 14:25:41.140612 : CSSD:1117321536: clssnmrCheckNodeWeight: stamp(311972654), completed(1/2)
2014-11-24 14:25:41.140615 : CSSD:1117321536: clssnmrCheckSplit: Waiting for node weights, stamp(311972654)
2014-11-24 14:25:41.188880 : CSSD:1084811584: clssnmvDiskKillCheck: not evicted, file /dev/raw/raw2 flags 0x00000000, kill block unique 0, my unique 1416805718
2014-11-24 14:25:41.558921 : CSSD:1114167616: clssnmvDiskPing: Writing with status 0x3, timestamp 1416810341/1022717334
2014-11-24 14:25:41.731912 : CSSD:1086388544: clssnmvDHBValidateNCopy: node 1, node1, has a disk HB, but no network HB, DHB has rcfg 311972655, wrtcnt, 9527468, LATS 102 2717514, lastSeqNo 9527467, uniqueness 1416808381, timestamp 1416810341/1022722074
2014-11-24 14:25:41.731928 : CSSD:1086388544: clssnmvReadDskHeartbeat: manual shutdown of nodename node1, nodenum 1 epoch 1416810341 msec 1022722074
2014-11-24 14:25:41.732266 : CSSD:1117321536: clssnmrCheckNodeWeight: node(2) has weight stamp(311972654), pebble(3)
2014-11-24 14:25:41.732273 : CSSD:1117321536: clssnmrCheckNodeWeight: stamp(311972654), completed(1/1)
2014-11-24 14:25:41.732294 : CSSD:1117321536: clssnmCheckDskInfo: My cohort: 2
2014-11-24 14:25:41.732299 : CSSD:1117321536: clssnmRemove: Start
2014-11-24 14:25:41.732306 : CSSD:1117321536: (:CSSNM00007:)clssnmrRemoveNode: Evicting node 1, node1, from the cluster in incarnation 311972655, node birth incarnation 311972654, death incarnation 311972655, stateflags 0x225000 uniqueness value 1416808381 The number of the resource executing on each node and others are considered by the weight. Reference

 

 

11g:调度程序维护任务或 Autotasks (Doc ID 1526120.1)

适用于:

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 466920.1 – 11g New Feature: Health Monitor

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 程序。

SQL> execute DBMS_AUTO_TASK_ADMIN.DISABLE;

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

SQL> BEGIN
dbms_auto_task_admin.disable(
client_name => ‘sql tuning advisor’,
operation => NULL,
window_name => NULL);
END;
/

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

SQL> BEGIN
dbms_auto_task_admin.enable(
client_name => ‘sql tuning advisor’,
operation => NULL,
window_name => NULL);
END;
/

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

示例:

auto optimizer stats collection
auto space advisor
sql tuning advisor

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

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

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

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

您可以使用 DBMS_SCHEDULER.SET_ATTRIBUTE 程序调整预定义维护窗口时间,使其适用于您的数据库环境。
示例:以下脚本将 WEEKNIGHT_WINDOW 改为每个工作日从午夜至上午 8 点(窗口持续时间为 8 小时不变):
EXECUTE DBMS_SCHEDULER.SET_ATTRIBUTE(
‘WEEKNIGHT_WINDOW’,
‘repeat_interval’,
‘freq=daily;byday=MON, TUE, WED, THU, FRI;byhour=0;byminute=0;bysecond=0’);

每个窗口还有一个名为 DEFAULT_MAINTENANCE_PLAN 的预定义资源计划,一旦打开相关窗口,该计划将激活。这是 10g 和 11g 之间的另一个差异。


SQL> select window_name, resource_plan from dba_scheduler_windows;

WINDOW_NAME                    RESOURCE_PLAN
—————————— ——————————
MONDAY_WINDOW                  DEFAULT_MAINTENANCE_PLAN
TUESDAY_WINDOW                 DEFAULT_MAINTENANCE_PLAN
WEDNESDAY_WINDOW               DEFAULT_MAINTENANCE_PLAN
THURSDAY_WINDOW                DEFAULT_MAINTENANCE_PLAN
FRIDAY_WINDOW                  DEFAULT_MAINTENANCE_PLAN
SATURDAY_WINDOW                DEFAULT_MAINTENANCE_PLAN
SUNDAY_WINDOW                  DEFAULT_MAINTENANCE_PLAN
WEEKNIGHT_WINDOW
WEEKEND_WINDOW

9 rows selected.

SQL> select * from dba_rsrc_plans where plan=’DEFAULT_MAINTENANCE_PLAN’
PLAN_ID PLAN NUM_PLAN_DIRECTIVES
———- —————————— ——————-
CPU_METHOD MGMT_METHOD
—————————— ——————————
ACTIVE_SESS_POOL_MTH PARALLEL_DEGREE_LIMIT_MTH
—————————— ——————————
QUEUEING_MTH SUB
—————————— —
COMMENTS
——————————————————————————–
STATUS MAN
—————————— —
11187 DEFAULT_MAINTENANCE_PLAN 4
EMPHASIS EMPHASIS
ACTIVE_SESS_POOL_ABSOLUTE PARALLEL_DEGREE_LIMIT_ABSOLUTE
FIFO_TIMEOUT NO
Default plan for maintenance windows that prioritizes SYS_GROUP operations and a
llocates the remaining 5% to diagnostic operations and 25% to automated maintena
nce operations.
YES
SQL> select * from DBA_RSRC_PLAN_DIRECTIVES where plan=’DEFAULT_MAINTENANCE_PLAN’;

PLAN GROUP_OR_SUBPLAN TYPE
—————————— —————————— ————–
CPU_P1 CPU_P2 CPU_P3 CPU_P4 CPU_P5 CPU_P6 CPU_P7
———- ———- ———- ———- ———- ———- ———-
CPU_P8 MGMT_P1 MGMT_P2 MGMT_P3 MGMT_P4 MGMT_P5 MGMT_P6
———- ———- ———- ———- ———- ———- ———-
MGMT_P7 MGMT_P8 ACTIVE_SESS_POOL_P1 QUEUEING_P1 PARALLEL_DEGREE_LIMIT_P1
———- ———- ——————- ———– ————————
SWITCH_GROUP SWITC SWITCH_TIME SWITCH_IO_MEGABYTES
—————————— —– ———– ——————-
SWITCH_IO_REQS SWITC MAX_EST_EXEC_TIME UNDO_POOL MAX_IDLE_TIME
————– —– —————– ———- ————-
MAX_IDLE_BLOCKER_TIME SWITCH_TIME_IN_CALL
——————— ——————-
COMMENTS
——————————————————————————–
STATUS MAN
—————————— —
DEFAULT_MAINTENANCE_PLAN SYS_GROUP CONSUMER_GROUP
100 0 0 0 0 0 0
0 100 0 0 0 0 0
0 0
FALSE
FALSE

Directive for system operations
NO

DEFAULT_MAINTENANCE_PLAN OTHER_GROUPS CONSUMER_GROUP
0 70 0 0 0 0 0
0 0 70 0 0 0 0
0 0
FALSE
FALSE

Directive for all other operations
NO

DEFAULT_MAINTENANCE_PLAN ORA$AUTOTASK_SUB_PLAN PLAN
0 25 0 0 0 0 0
0 0 25 0 0 0 0
0 0
FALSE
FALSE

Directive for automated maintenance tasks
NO

DEFAULT_MAINTENANCE_PLAN ORA$DIAGNOSTICS CONSUMER_GROUP
0 5 0 0 0 0 0
0 0 5 0 0 0 0
0 0
FALSE
FALSE

Directive for automated diagnostic tasks
NO

10g 与 11g 之间变化的摘要:

主题 10g 11g
作业 在 DBA_SCHEDULER_JOBS 中独立作业 AUTOTASKS 有命名前缀“ORA$AT”,且只有作业执行后才可见
维护窗口 2 个窗口:WEEKNIGHT 和 WEEKEND 每天有不同的窗口
Resource manager 默认不启用 每个窗口都有预定义资源计划

相关视图:

DBA_AUTOTASK_CLIENT
DBA_AUTOTASK_CLIENT_HISTORY
DBA_AUTOTASK_CLIENT_JOB
DBA_AUTOTASK_JOB_HISTORY
DBA_AUTOTASK_OPERATION
DBA_AUTOTASK_SCHEDULE
DBA_AUTOTASK_TASK
DBA_AUTOTASK_WINDOW_CLIENTS
DBA_AUTOTASK_WINDOW_HISTORY

如何选择或更改数据库字符集 (NLS_CHARACTERSET) (Doc ID 1525394.1)

适用于:

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

用途

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

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

conn / as sysdba
select value from NLS_DATABASE_PARAMETERS where parameter=’NLS_CHARACTERSET’;

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

要更改 Oracle Application 数据库的 NLS_CHARACTERSET请参阅 Note 124721.1 Migrating an Applications Installation to a New Character Set.
这是 Oracle Application 唯一支持的方法。如果您有任何疑问,请开一个 Oracle Applications SR 以寻求帮助。

适用范围

尝试更改 NLS_CHARACTERSET 的所有用户。

现在仍然有数据库管理员尝试通过修改 props$ 来更改 NLS_CHARACTERSET NLS_NCHAR_CHARACTERSET。我们不支持使用这种方法因为这将会损坏您的数据库。这是破坏整个数据集的最直接方式之一。如果您已经做了这个操作,那么第一件事就是从备份中完全恢复数据库.如果没有做任何备份,那么Oracle Support 可以尝试帮助您进行恢复 Oracle 不能保证可以恢复数据也不能保证恢复后的数据完全正确。我们会要求您执行完全导出操作,并重新建立整个数据库。

 
切勿更新 props$

详细信息

 

A) 数据库字符集 (NLS_CHARACTERSET)

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

需要注意的是 NLS_LANGUAGE 和 NLS_TERRITORY 同数据库是否有能力存储某种字符没有任何关系。
一个使用 NLS_CHARACTERSET 为 WE8MSWIN1252 并且 NLS_LANGUAGE/NLS_TERRITORYJAPANESE 为 JAPAN 的数据库是不能存储日文的,因为 WE8MSWIN1252 中不包含日文字符的定义。
一个使用 NLS_CHARACTERSET 为 AL32UTF8 并且 NLS_LANGUAGE/NLS_TERRITORY 为 AMERICAN AMERICA 的数据库能存储日文 (或者从某种意义上说任何世界上其它的语言).

如果您准备修改数据库的字符集,并且当前使用的某些字符在新的字符集中没有定义,或者当前字符集的设置是不正确的,那么在字符集修改之后就可能发生数据丢失。
在更改字符集前应始终使用 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

切勿在字符数据类型(CHARVARCHAR2LONGCLOB)中存储二进制(加密)数据。
如果将二进制数据作为 CHARVARCHAR2LONG  CLOB 数据类型存储/处理,则可能会丢失数据,特别是在使用 AL32UTF8 数据库时(即使没有使用导出/导入操作)。或者,可能会出现 ORA-29275 ORA-600 [kole_t2u], [34] 等错误。

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

 

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,都已经默认安装了.

您不能将 AL16UTF16 作为 NLS_CHARACTERSET,AL16UTF16 只能作为 NLS_NCHAR_CHARACTERSET,请参阅 Note:276914.1 The National Character Set in Oracle 9i 10g and 11g
人们经常会有一个错误的认识,认为简单的使用NCHAR, NVARCHAR2 和 NCLOB就可以让应用程序变得Unicode化,并且比改变NLS_CHARACTERSET花费的工作更少.
但是一般的N-类型在编程语言以及应用的角度上的支持是很差的.为了使用N-类型,应用程序需要显式的支持.
所以Oracle一般建议使用NLS_CHARACTERSET, CHAR, VARCHAR2 , LONG 和 CLOB 这样的数据类型,而不是N-类型的数据类型.

对于非 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 不保证该网站中的信息完全正确。

* 对数据库(RDBMS)的升级是不会改变 NLS_CHARACTERSET 的,所以将数据库从 9i 或 10g 升级到 11g 或 12c 后 NLS_CHARACTERSET 还会是原来的值。

* 如果您计划将数据库从一个不推荐的8位字符集(比如US7ASCII 或 WE8ISO8859P1),改为一个推荐的8位字符集(比如WE8MSWIN1252),请参见 C3 中提供的步骤。在没有对源数据库运行 csscan 前,不要尝试做 export 和 import!

 

从版本 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

需要注意的是重建 control 文件不会改变 NLS_CHARACTERSET。CREATE CONTROLFILE DATABASE … RESETLOGS ….CHARACTER SET <NLS_CHARACTERSET> 中的字符集(从 ALTER DATABASE BACKUP CONTROLFILE TO TRACE..得到的)需要同数据库的 NLS_CHARACTERSET 一致。

要确保数据库中没有使用字符集相关的数据类型(CHAR, VARCHAR2, LONG, CLOB)来存储二进制的文件(pdf , doc, docx, jpeg, png等文件)或者加密的数据(passwords).
如果二进制文件(如PDF , doc, docx, jpeg, png等)或者加密的数据(passwords)存成了CHAR, VARCHAR2, LONG 或 CLOB ,那么就很可能会发生数据的丢失,尤其当使用AL32UTF8的数据库的时候(就算没有使用exp/imp)
或者像ORA-29275 或 ORA-600 [kole_t2u], [34]这样的错误就会发生.
唯一支持存储二进制数据或加密的数据的数据类型是LONG RAW 或者 BLOB.
如果你想把二进制数据或加密的数据存储在CHAR, VARCHAR2, LONG or CLOB数据类型里,那么它们在application端必须被转换成”characterset safe”的形式,比如base64.
Note 1297507.1 Problems with (Importing) Encrypted Data After Character Set Change Using Other NLS_CHARACTERSET Database or Upgrading the (client) Oracle Version

 

 

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.

在所有 10g 版本(包括 10.1.0.5 和 10.2.0.3)和 11.1.0.6 中,使用数据抽取时,将 8 位字符集更改为 UTF8 / AL32UTF8 或其他多字节字符集可能会损坏数据。除非已应用 Patch 5874989 ,否则 Impdp 可能会损坏数据。
“旧”的导出/导入功能可以正常工作。10.2.0.4 和 11.1.0.7 补丁集中已修正此问题。

以下链接中包括了此故障的所有现有补丁集:https://updates.oracle.com/download/5874989.html

对于 Windows,修正程序包括在
10.1.0.5.0 Patch 20 (10.1.0.5.20P) 或更高版本中 ( Note 276548.1 )
10.2.0.3.0 Patch 11 (10.2.0.3.11P) 或更高版本中 ( Note 342443.1 )

从技术角度看,只需要在 impdp 端应用补丁集,但是如果您在不同的字符集之间使用 expdp/impdp,我们建议您对所有系统应用补丁集。

注意对于 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) 的分步指南(包括导出/导入操作)

人们经常会有一个错误的认识,认为简单的使用NCHAR, NVARCHAR2 和 NCLOB就可以让应用程序变得Unicode化,并且比改变NLS_CHARACTERSET花费的工作更少.
However N-types are rather poorly supported in (other vendor) programming languages and on application level in general.
但是一般的N-类型在编程语言以及应用的角度上的支持是很差的.为了使用N-类型,应用程序需要显式的支持.
所以Oracle一般建议使用NLS_CHARACTERSET, CHAR, VARCHAR2 , LONG 和 CLOB 这样的数据类型,而不是N-类型的数据类型.

转换到 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).

R12c 新特性:RMAN 可插拔数据库的备份和恢复 (Doc ID 1945849.1)

适用于:

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 中:

 

% rman target sys/<pw>@t12ccdb
RMAN> report schema;using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name T12CCDB
** (filenames have been edited for clarity)List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
—- ——– ——————– ——- ————————
1    960      SYSTEM                 ***     …/oradata/T12CCDB/datafile/o1_mf_system_8008cm5s_.dbf
3    660      SYSAUX                 ***     …/oradata/T12CCDB/datafile/o1_mf_sysaux_80089voz_.dbf
4      50     UNDOTBS1             ***     …/oradata/T12CCDB/datafile/o1_mf_undotbs1_8gtp7g6l_.dbf
5    250     PDB$SEED:SYSTEM  ***     …/oradata/T12CCDB/C4B70772D4DF1DF8E0437108DC0A7D20/datafile/o1_mf_system_8008jc7k_.dbf
6       5     USERS                    ***     …/oradata/T12CCDB/datafile/o1_mf_users_8008fnov_.dbf
7    490     PDB$SEED:SYSAUX  ***     …/oradata/T12CCDB/C4B70772D4DF1DF8E0437108DC0A7D20/datafile/o1_mf_sysaux_8008jc8m_.dbf
8    250     T12CPDB1:SYSTEM  ***     …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_system_8008r3wh_.dbf
9    510     T12CPDB1:SYSAUX  ***     …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_sysaux_8008r3vl_.dbf
10     5     T12CPDB1:USERS     ***     …/oradata/T12CCDB/datafile/o1_mf_users_8gtp7ghf_.dbf
20  100     T12CPDB1:RECTBL   ***     …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_rectbl_8hfcv26r_.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
—- ——– ——————– ———– ——————–
1    530      TEMP                      32767       …/oradata/T12CCDB/datafile/o1_mf_temp_8bz0jcxg_.tmp
2    20       PDB$SEED:TEMP        32767       …/oradata/T12CCDB/C40F9B49FC9C19E0E0430BAAE80AFF01/datafile/o1_mf_temp_8bz0jfkj_.tmp
3    20       T12CPDB1:TEMP       32767       …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_temp_8bz0jh7x_.tmp

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

% rman target sys/<pw>@t12cpdb1
RMAN> report schema;List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
—- ——– ——————– ——- ————————
8    250      T12CPDB1:SYSTEM      ***     …/oradata/T12CCDB/datafile/o1_mf_system_8hloc72d_.dbf
9    510      T12CPDB1:SYSAUX      ***     …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_sysaux_8008r3vl_.dbf
10   5         T12CPDB1:USERS       ***     …/oradata/T12CCDB/datafile/o1_mf_users_8hlowbh2_.dbf
20   100      T12CPDB1:RECTBL      ***     …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_rectbl_8hfcv26r_.dbfList of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
—- ——– ——————– ———– ——————–
3    20       T12CPDB1:TEMP        32767       …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_temp_8bz0jh7x_.tmp

1. 完整容器数据库备份

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

% rman target sys/<pw>@t12ccdb
RMAN> BACKUP DATABASE PLUS ARCHIVELOG ALL DELETE INPUT;
RMAN> LIST BACKUP OF DATABASE;List of Backup Sets
===================…
——- —- — ———- ———– ———— —————
82      Full    2.46G      DISK        00:01:01     17-JAN-13
BP Key: 83   Status: AVAILABLE  Compressed: NO  Tag: TAG20130117T114547
Piece Name: …/fast_recovery_area/T12CCDB/backupset/2013_01_17/o1_mf_nnndf_TAG20130117T114547_8hhs3cgs_.bkp
List of Datafiles in backup set 82
File LV Type Ckp SCN    Ckp Time  Name
—- — —- ———- ——— —-
1       Full 2139245    17-JAN-13 …/oradata/T12CCDB/datafile/o1_mf_system_8008cm5s_.dbf
3       Full 2139245    17-JAN-13 …/oradata/T12CCDB/datafile/o1_mf_sysaux_80089voz_.dbf
4       Full 2139245    17-JAN-13 …/oradata/T12CCDB/datafile/o1_mf_undotbs1_8gtp7g6l_.dbf
5       Full 1621614    13-JUL-12 …/oradata/T12CCDB/C4B70772D4DF1DF8E0437108DC0A7D20/datafile/o1_mf_system_8008jc7k_.dbf
6       Full 2139245    17-JAN-13 …/oradata/T12CCDB/datafile/o1_mf_users_8008fnov_.dbf
7       Full 1621614    13-JUL-12 …/oradata/T12CCDB/C4B70772D4DF1DF8E0437108DC0A7D20/datafile/o1_mf_sysaux_8008jc8m_.dbf
8       Full 2139245    17-JAN-13 …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_system_8008r3wh_.dbf
9       Full 2139245    17-JAN-13 …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_sysaux_8008r3vl_.dbf
10      Full 2139245    17-JAN-13 …/oradata/T12CCDB/datafile/o1_mf_users_8gtp7ghf_.dbf
20      Full 2139245    17-JAN-13 …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_rectbl_8hfcv26r_.dbf

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

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

%rman target sys/<pw>@t12ccdb
RMAN> BACKUP PLUGGABLE DATABASE T12CPDB1 TAG ‘T12CPDB1’;
RMAN> LIST BACKUP;…
——- —- — ———- ———– ———— —————
85      Full    590.52M    DISK        00:00:14     17-JAN-13
BP Key: 86   Status: AVAILABLE  Compressed: NO  Tag: T12CPDB1
Piece Name: …/fast_recovery_area/T12CCDB/backupset/2013_01_17/o1_mf_nnndf_T12CPDB1_8hhswy1c_.bkp
List of Datafiles in backup set 85
Container ID: 3, PDB Name: T12CPDB1
File LV Type Ckp SCN    Ckp Time  Name
—- — —- ———- ——— —-
8       Full 2139742    17-JAN-13 …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_system_8008r3wh_.dbf
9       Full 2139742    17-JAN-13 …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_sysaux_8008r3vl_.dbf
10      Full 2139742    17-JAN-13 …/oradata/T12CCDB/datafile/o1_mf_users_8gtp7ghf_.dbf
20      Full 2139742    17-JAN-13 …/oradata/T12CCDB/C4B71645EF062616E0437108DC0A91E4/datafile/o1_mf_rectbl_8hfcv26r_.dbf

 

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

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

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

登录容器数据库:

SQL> SET LINES 150
SQL> SELECT CON_ID, DBID, CON_UID, GUID, NAME FROM v$pdbs;

 

CON_ID       DBID    CON_UID                                       GUID                             NAME
———- ———-       ———-       ——————————– ——————————
2  4031181962  4031181962  C40F9B49FC9C19E0E0430BAAE80AFF01       PDB$SEED
       3    575001283     575001283  C4B71645EF062616E0437108DC0A91E4      T12CPDB1

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

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

% rman target sys/<pw>@t12ccdb
RMAN>BACKUP TABLESPACE T12CPDB1:SYSTEM, T12CPDB1:SYSAUX;

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

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

% rman target sys/<pw>@t12ccdb
RMAN>BACKUP TABLESPACE T12CPDB1:SYSTEM, SYSAUX;

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

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

% rman target sys/<pw>@t12ccdb
RMAN> BACKUP DATAFILE 3,20;

RMAN 可插拔数据库的恢复

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

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

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

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

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

% rman target /
RMAN> RESTORE DATAFILE 8;
RMAN> RECOVER DATAFILE 8;
RMAN> ALTER PLUGGABLE DATABASE T12CPDB1 OPEN;

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

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

% rman sys/<pw>@t12cpdb1
RMAN> ALTER DATABASE DATAFILE 10 OFFLINE;
RMAN> RESTORE DATAFILE 10;
RMAN> RECOVER DATAFILE 10;
RMAN> ALTER DATABASE DATAFILE 10 ONLINE;

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

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

% rman target sys/oracle@t12ccpdb1
RMAN> ALTER TABLESPACE USERS OFFLINE;
RMAN> RESTORE TABLESPACE USERS;
RMAN> RECOVER TABLESPACE USERS;
RMAN> ALTER TABLESPACE USERS ONLINE;

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

% rman target sys/<pw>@t12ccdb
RMAN> RESTORE PLUGGABLE DATABASE T12CPDB1;
RMAN> RECOVER PLUGGABLE DATABASE T12CPDB1;
RMAN> ALTER PLUGGABLE DATABASE T12cPDB1 open;

注:

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

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

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

RMAN-06813: could not translate pluggable database PDB1

 

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

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

如何生成 AWR 报告和 AWR 基线 (Doc ID 2331572.1)

适用于:

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 报告:

$ORACLE_HOME/rdbms/admin/awrrpt.sql

基于不同的原因,通常可以采用默认的设置来产生 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; 
/

 

注意:在 11g 中引入了一个新的存储过程 DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE 可以制定一个模板来管理在未来时间怎样创建 AWR 基线:

 

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,参见:

Document 1490798.1 AWR Reporting – Licensing Requirements Clarification

对于 SQL 性能问题如何收集诊断信息 (Doc ID 2293025.1)

适用于

产品:

  • Oracle Database – 企业版 – 版本 6.0.0.0 及更高版本
  • 本文档内容适用于任何平台

需要的权限:

  • 数据库管理员 – 需要访问数据库来收集数据

系统影响:

  • 无 – 以下的收集指令不会对系统有任何影响
哪些会被收集以及为什么?

提供一步步的指导来对 SQL 性能问题收集诊断日志。

Action Plan

诊断文件列表

 1) 使用 SQL Health Check 检查语句                                  [  ]
 2) 使用 SQLT 的 XTRXEC 模式收集诊断信息                              [  ]
 
 如果不能收集 SQLT
 
 2) 手工收集诊断日志                                                 [  ]
   a) 语句的全文 – 完整的有问题的语句的 SQL 文本                        [  ]
   b) 收集有问题的执行计划                                            [  ]
   c) 收集好的执行计划(如果有的话)                                    [  ]
   d) 收集有问题时的 10046 trace                                     [  ]
   e) 收集没问题时的 10046 trace(如果有的话)                         [  ]

 整理并上传诊断日志

 3) 整理并上传诊断日志                                                [  ]

 

性能问题的诊断信息

 

1) 使用 SQL Health Check 检查语句

下载并运行 SQLHC 工具

# sqlplus / as sysdba
SQL> START sqlhc.sql [T|D|N] [SQL_ID]

关于如何使用 SQLHC 收集 SQL 性能问题的信息,请参照下面的文章:

Document 1903134.1 How to Collect Standard Diagnostic Information Using SQLHC for SQL Performance and Incorrect Result Issues

检查 SQLHC 的推荐

检查 SQL Health Check 工具的推荐,如果文件 sqlhc_IDENTIFIER_1_health_check.html 中的内容不能帮我们解决问题,那么上传 SQLHC 输出到 SR。

 

 

2) 使用 SQLT 的 XTRXEC 模式收集诊断信息

除了 SQLHC 的输出,收集这个语句的 SQLT 输出。你需要先下载并安装 SQLT。以 XTRXEC 模式收集 SQLT,这样同时收集到运行时以及优化器的信息。

注意:如果语句不能在一个合理的时间内运行完毕或者语句会修改数据(比如 INSERT/UPDATE/DELETE 语句),那么以 XTRACT(sqltxtract.sql)模式收集,它不会真的去执行语句,而仅仅收集之前执行产生的信息。

XTRXEC 模式收集足够的信息(包括运行这个语句),如下:

使用 SQL*PLUS 以执行有问题语句的应用账号连接,并执行 sqlt/run/sqltxtrxec.sql 脚本,并提供 SQL_ID 或者 HASH_VALUE。

# cd sqlt/run
# sqlplus apps
SQL> START sqltxtrxec.sql [SQL_ID]|[HASH_VALUE]

如果这个语句有正常的时候(比如在其他的系统上,或者不同版本,或者不同的用户下,或者在不同的参数下),那么也同时收集正常时候的 SQLT 以做对比。

如果如何使用 SQLT 收集 SQL 性能问题的诊断日志,请参考下面的文章:

Document 1683772.1 How to Collect Standard Diagnostic Information Using SQLT for SQL Performance and Incorrect Result Issues

 

 

如果不能收集 SQLT

2) 手工收集诊断日志

SQLT 可以一次运行就收集大部分诊断性能问题所需要的信息,但是如果因为一些原因您不能使用 SQLT,那么您需要手工收集下面的信息。

 

2a) 语句的全文 – 完整的有问题的语句的 SQL 文本

收集问题语句的文本全文

 

2b) 收集有问题的执行计划

在 10.2 及更高版本上,如果语句已经执行了,可以从 library cache 中拿到执行计划(和之前的版本只能收集标准的执行计划相比)。要收集最近一次执行的执行计划,执行下面的命令:

SQL> set linesize 150
SQL> set pagesize 2000
SQL> spool problem_explain.txt

SQL> select * from table(dbms_xplan.display_cursor(null,null, ‘ALL’));

SQL> spool off

关于更多方法,请参考:

Document 1683772.1 How to Obtain a Formatted Explain Plan – Recommended Methods

 

2c) 收集好的执行计划(如果可能的话)

如果有好的执行计划,那么像上面一样收集好的执行计划,spool 到一个”good_explain.txt”的文件中。

 

2d) 收集有问题时候的 10046 trace

在 session level 收集这个语句的 10046 trace:

alter session set tracefile_identifier=’problem_10046′;

alter session set timed_statistics = true;
alter session set statistics_level=all;
alter session set max_dump_file_size = unlimited;

oradebug setmypid
oradebug tracefile_name

alter session set events ‘10046 trace name context forever,level 12’;

— 在这里执行需要被 trace 语句或者操作 —

select * from dual;
exit;

trace 文件会显示在”oradebug tracefile_name” 命令的输出中。

注意:如果并未使用绑定变量,那么使用 level 8,因为 level 12 会产生更大的日志。

如果语句无法在合理的时间内完成,那么就 trace 一个合理的时间后,就取消它。

如果 session 不能退出,那么可以执行下面的语句关闭 trace:

alter session set events ‘10046 trace name context off’;

关于更多收集 10046 trace 的方式,请参考文档:

Document 376442.1 Recommended Method for Obtaining 10046 trace for Tuning

 

2e) 收集没问题时候的 10046 trace(如果可能的话)

如果语句有正常的时候,那么也对好的时候收集 10046 trace,使用’good_10046′ 作为 trace 的标识: 

alter session set tracefile_identifier=’good_10046′;

 

 

下一步

3) 整理并上传诊断日志

如果在检查和实施了 SQL Health Check 的推荐后,仍然无法解决问题,那么可以从下面的文档中找到更多分析 SQL 性能问题的方式:

Document 742112.1 Troubleshooting Query Performance Degradation – Recommended Actions

如果无法解决问题,整理并上传诊断日志给技术支持,并且提供一个清晰的问题描述。在大部分情况下这些信息已经足够,但还是有些情况会要收集更多的信息。

SQL Health Check 输出文件:sqlhc_IDENTIFIER_1_health_check.html
语句的 XTRACT 模式的 SQLT 输出
如果不能收集 SQLT,上传

  • 语句的全文
  • 有问题的执行计划
  • 收集好的执行计划(如果有的话)
  • 有问题时候的 10046 trace
  • 没问题时候的 10046 trace(如果有的话)

SQL 自动调优以及 SQL Profile (Doc ID 2331566.1)

适用于:

 

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

用途

 

SQL Profiles 是10g 引入的新特性,它通过 DBMS_SQLTUNE 包来管理,您也可以通过 Oracle Enterprise Manager 的自动 SQL 调优流程的功能来管理。这个 FAQ 回答关于 SQL profile 基本的问题,并且提供了一个使用 DBMS_SQLTUNE 包的例子。

 

提问,获得帮助,并分享您对于这篇文档的经验。

 

您是否希望与其他 Oracle 客户、Oracle 员工和业内专家进一步探讨此主题?

 

请点击这里 进入 Oracle 社区(中文).
请点击这里进入My Oracle Support 社区的数据库安装/升级(英文)主页发现更多的话题和讨论。

问题和答案

 

什么是自动 SQL 调优?

 

有时候,因为缺乏相关的统计信息,会导致 SQL 优化器不能产生精准的评估,导致产生了差的执行计划。
一般的办法是用户不得不以手工在程序代码里面添加一些 hint 来指导优化器产生好的执行计划。对于已经封装的应用程序来说,修改代码是不可行的,唯一的办法是给应用开发商提 bug 并等其修改。

 

自动 SQL 调优正好是为这种场景而设计的。自动调优优化器(Automatic Tuning Optimizer)可以为 SQL 文本创建一个 Profile,叫SQL profile,它是由和 sql 语句相关的辅助统计信息所组成。在正常模式下的查询优化器在评估数据量(cardinality),选择率(selectivity)和成本(cost)时,可能因为缺乏足够数量的信息而导致不准,SQL profile 可以通过收集附加的信息,如采样、部分执行等技术来验证评估是否准确,必要时会调整优化器的评估。

在 SQL Profile 工作时,自动调优优化器(Automatic Tuning Optimizer)也会使用 SQL 语句的历史执行信息来设置合适的优化器参数,例如把 OPTIMIZER_MODE 从ALL_ROWS 改成 FIRST_ROWS。

 

此类型的分析输出通常是推荐您接受这个 SQL Profile。

对于一个 SQL Profile,一旦被接受,就会持续的存在数据字典中。SQL Profile 是针对某个特定 SQL 有效的,如果被接受,工作在正常模式下的优化器就会连同 SQL Profile 中的信息和其他正常统计信息一起来生成执行计划。这些可用的附加信息使得针对某个特定 SQL 产生更优的执行计划成为可能,而这无需修改任何应用程序代码。

下面的文档提供更多关于 SQL 调优顾问(SQL Tuning Advisor)的信息。

Oracle® Database 2 Day DBA
12c Release 1 (12.1)
E17643-13
10 Monitoring and Tuning the Database

About the SQL Tuning Advisor

 

 

什么是 SQL Profile?

 

SQL Profile 是一些信息的集合体,存储在数据字典中,使得 SQL 优化器可以为 SQL 语句产生最优的执行计划。SQL Profile 包含自动 SQL 调优期间发现的对产生错误执行计划的评估的纠正信息。这些信息能改善优化器的数据量(cardinality),选择率(selectivity)评估,而这些信息会指引优化器找到更好的执行计划。

一个 SQL profile 不包含某个特定执行计划的相关联信息,相反,优化器当选择执行计划的时候参考如下信息数据:

  • 环境信息,包括数据库配置,绑定变量值,统计信息,数据集等等
  • 存储在 SQL profile 中的补充信息

需要提醒的是,SQL Profile 不会像存储纲要(stored outlines)那样固定一个 SQL 的执行计划,当表的数据量增长或者有索引创建或删除时,使用了 SQL Profile 的执行计划仍会及时调整,也就是说,当数据分布或访问路径变化后,存储在 SQL Profile 中的相关信息仍然被参考。当然,经过相当长时间后,它的内容可能变得陈旧过时,需要重新生成。您可以通过再次运行自动 SQL 调优(Automatic SQL Tuning)来重新生成这个 SQL 的 Profile。

 

SQL Profile 的范围如何控制?

 

SQL Profile 的范围可以通过 CATEGORY 属性来控制,这个属性决定了哪个 sessoin 可以使用这个 profile,您可以通过查看 DBA_SQL_PROFILES 视图的 CATEGORY 字段来了解相关信息。

select category,name from dba_sql_profiles;

默认情况下,所有的 profiles 都被指定为 DEFAULT category,这就意味着所有 session 当初始化参数 SQLTUNE_CATEGORY 设置 DEFAULT 的时候都可以用这个 profile。

通过修改 SQL profile 的 category 属性,你可以指定哪个 session 受 profile 影响。例如,设置 category 为 DEV,那么 session 级设置了初始化参数 SQLTUNE_CATEGORY 为 DEV 的那些 session 可以使用这个 profile,其他 session 则不能使用这个 SQL profile,执行计划当然也不会受这个 SQL profile 影响。这个特性可以让您用来在某个限制环境上提前测试某个 SQL profile 而避免影响其他 session。

 

SQL Profile 适用什么语句??

 

SELECT 语句
UPDATE 语句
INSERT 语句(必须包含select语句)
DELETE 语句
CREATE TABLE 语句(必须包含 AS SELECT 子句)
MERGE 语句(update 或者 insert 操作)

 

如何管理 SQL Profile?

SQL Profiles 可以通过 Oracle 企业管理器(Enterprise Manager)的自动 SQL 调优流程部分来管理它,或者通过 DBMS_SQLTUNE 包。

 

使用企业管理器:

  1. 在 Performance 页面, 点击 Top Activity。
    Top Activity 页面出现。
  2. 在 Top SQL 下, 点击使用 SQL profile 的 SQL 语句的 SQL ID 链接。
    SQL Details 页面显示出来。
  3. 点击 Plan Control 栏。
    SQL Profiles 和 Outlines 部分会显示 SQL Profile 的列表。
  4. 选择想要管理的 SQL profile。
    执行下面的任意操作 one of the following:

    • 要启用一个当前被禁用的 SQL profile,点击 Disable/Enable。
    • 要禁用一个当前被启用的 SQL profile,点击 Disable/Enable。
    • 要删除一个 SQL profile,点击 Delete.
  5. Confirmation 页面显示出来。
    点击 Yes 来确认,或者 No 取消刚才的操作。

 

使用 DBMS_SQLTUNE 包:

若是用 SQL Profiles APIs,您需要有 CREATE ANY SQL_PROFILE,DROP ANY SQL_PROFILE,ALTER ANY SQL_PROFILE 等系统权限。

 

接受 SQL Profile

使用 DBMS_SQLTUNE.ACCEPT_SQL_PROFILE 存储过程来接受一个 SQL Tuning Advisor 推荐的 SQL Profile。这会创建 SQL Profile 并存储在数据字典中。

DECLARE
my_sqlprofile_name VARCHAR2(30);
BEGIN
my_sqlprofile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE (
task_name => ‘my_sql_tuning_task’,
name => ‘my_sql_profile’);
END;

my_sql_tuning_task 是一个 SQL 调优任务的名字,您可以通过 DBA_SQL_PROFILES 来查看一个 SQL Profile 的相关信息。

 

修改 SQL Profile

您可以通过 ALTER_SQL_PROFILE 来修改一个已知 SQL Profile 的状态,名字,描述信息和 CATEGORY 属性。

BEGIN
DBMS_SQLTUNE.ALTER_SQL_PROFILE(
name => ‘my_sql_profile’,
attribute_name => ‘STATUS’,
value => ‘DISABLED’);
END;
/

这个例子中,my_sql_profile 是您想要修改的 SQL Profile 名字。
状态被设置成 disabled,意思是 SQL Profile 将不会被 SQL 使用。

 

删除 SQL Profile

可以通过 DROP_SQL_PROFILE 来删除 SQL Profile。

begin
DBMS_SQLTUNE.DROP_SQL_PROFILE(name => ‘my_sql_profile’);
end;
/

 

 

样例:

SESSION 1 — SCOTT

创建表,插入数据,创建索引并收集统计信息。
执行带有 no_index hint 的 SQL,全表扫描将会被使用:

SQL> create table test (n number );
Table created.
SQL> declare
begin
for i in 1 .. 10000 loop
insert into test values(i);
commit;
end loop;
end;
/
PL/SQL procedure successfully completed.
SQL> create index test_idx on test(n);
Index created.
SQL> exec dbms_stats.gather_table_stats(”,’TEST’);
PL/SQL procedure successfully completed.
set autotrace on
select /*+ no_index(test test_idx) */ * from test where n=1;

 
Plan hash value: 217508114

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |     4 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TEST |     1 |     4 |     4   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("N"=1)

SESSION 2 — SYS

创建并执行调优任务并查询它的输出结果。
然后接受一个推荐的 SQL Profile

declare
my_task_name VARCHAR2(30);
my_sqltext CLOB;
begin
my_sqltext := ‘select /*+ no_index(test test_idx) */ * from test where n=1’;
my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
sql_text => my_sqltext,
user_name => ‘SCOTT’,
scope => ‘COMPREHENSIVE’,
time_limit => 60,
task_name => ‘my_sql_tuning_task_2’,
description => ‘Task to tune a query on a specified table’);
end;
/
PL/SQL procedure successfully completed.
begin
DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => ‘my_sql_tuning_task_2’);
end;
/
PL/SQL procedure successfully completed.
set long 10000
set longchunksize 1000
set linesize 100
set heading off
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( ‘my_sql_tuning_task_2’) from DUAL;
set heading on

Output:

GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name   : my_sql_tuning_task_2
Tuning Task Owner  : SYS
Workload Type      : Single SQL Statement
Scope              : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status  : COMPLETED
Started at         : 09/24/2012 12:36:44
Completed at       : 09/24/2012 12:36:49
-------------------------------------------------------------------------------
Schema Name: SCOTT
SQL ID     : d4wgpc5g0s0vu
SQL Text   : select /*+ no_index(test test_idx) */ * from test where n=1
-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------
1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
A potentially better execution plan was found for this statement.
Recommendation (estimated benefit: 90.95%)
------------------------------------------
- Consider accepting the recommended SQL profile.
execute dbms_sqltune.accept_sql_profile(task_name =>
'my_sql_tuning_task_2', task_owner => 'SYS', replace => TRUE);
Validation results
------------------
The SQL profile was tested by executing both its plan and the original plan
and measuring their respective execution statistics. A plan may have been
only partially executed if the other could be run to completion in less time.
Original Plan  With SQL Profile  % Improved
-------------  ----------------  ----------
Completion Status:            COMPLETE          COMPLETE
Elapsed Time (s):             .001004           .000331      67.03 %
CPU Time (s):                    .001                 0        100 %
User I/O Time (s):                  0                 0
Buffer Gets:                       22                 2       90.9 %
Physical Read Requests:             0                 0
Physical Write Requests:            0                 0
Physical Read Bytes:                0                 0
Physical Write Bytes:               0                 0
Rows Processed:                     1                 1
Fetches:                            1                 1
Executions:                         1                 1
Notes
-----
1. Statistics for the original plan were averaged over 10 executions.
2. Statistics for the SQL profile plan were averaged over 10 executions.
-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------
1- Original With Adjusted Cost
------------------------------
Plan hash value: 217508114
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |     4 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TEST |     1 |     4 |     4   (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("N"=1)
2- Using SQL Profile
--------------------
Plan hash value: 1416057887
-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |     1 |     4 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| TEST_IDX |     1 |     4 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("N"=1)
-------------------------------------------------------------------------------

 

DECLARE
my_sqlprofile_name VARCHAR2(30);
begin
my_sqlprofile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE (
task_name => ‘my_sql_tuning_task_2’,
name => ‘my_sql_profile’);
end;
/PL/SQL procedure successfully completed.

SESSION 1 — SCOTT

再次运行 SQL
可以看到即便是有 no_index 暗示,索引仍然被使用了
注意:执行计划里面可以看到使用了 my_sql_profile

SQL> set autotrace on
SQL> select /*+ no_index(test test_idx) */ * from test where n=1;

Execution Plan                                                                
-------------------------------------------------------------------------     
Plan hash value: 1416057887                                                   
----------------------------------------------------------------------------- 
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     | 
----------------------------------------------------------------------------- 
|   0 | SELECT STATEMENT |          |     1 |     4 |     1   (0)| 00:00:01 | 
|*  1 |  INDEX RANGE SCAN| TEST_IDX |     1 |     4 |     1   (0)| 00:00:01 | 
----------------------------------------------------------------------------- 
Predicate Information (identified by operation id):                           
---------------------------------------------------                           
1 - access("N"=1)                                                          
---------------                                                               
Note                                                                          
-----                                                                         
- SQL profile "my_sql_profile" used for this statement                     

 

如何获取每个调优集的报告?

 

SELECT ‘SELECT d.id , d.owner , d.description , d.created , d.last_modified , d.statement_count, ss.*
FROM TABLE(DBMS_SQLTUNE.select_sqlset (”’||name||”’)) ss, dba_sqlset d WHERE d.name=”’||name||”’;’
FROM dba_sqlset d
ORDER BY d.last_modified DESC.

Solix优化Oracle E-Business Suite性能

Solix优化Oracle E-Business Suite性能

沪ICP备14014813号

沪公网安备 31010802001379号