如何在脱机模式下载新的Oracle Cloud Control 12c的Agent软件

从OEM 12c开始,agent无法直接通过互联网可以下载,而需要在Self Update (自行更新)下载。但通常在生产环境中部署的OEM,出于安全考虑是没法直接连接互联网的。那么问题就来了,如果OEM是安装在Linux平台下,那么即只有对应平台的Agent软件。如果想要监管AIX或者HP-UNIX平台呢?本文就是为了解决此问题,如何在脱机模式中仍然使用self-update和补丁管理特性。

其他版本的下载可参考:http://www.oracle.com/technetwork/oem/grid-control/downloads/agentsoft-090381.html

1、首先,在OEM中通过“Setup(设置)”>“Extensibility(可扩展性)”>“ Self Update (自行更新)”。进入“ Self Update (自行更新)”配置页,查看“Connection Mode(连接模式)”的显示结果,必须是设置为”Offline”模式。

如下图:

OEM2

OEM1

2、返回“Self Update(自行更新)”配置页,点击“ Check Updates(检查更新)”,此时弹出“ Check updates in offline mode(在脱机模式中检查更新)”提示框,根据提示框,到可与Internet连接的主机上,先下载更新目录:

OEM3

比如:https://updates.oracle.com/Orion/Download/download_patch/p9348486_112000_Generic.zip

根据Use the following link to download the latest updates catalog 提供的网址,下载相应的文件后上传至OEM主机。

3、我们将使用emcli工具来导入catalog,emcli工具本身就已经安装在Manager Cloud Control server中的。如果没法正常使用,可以采用以下方式来安装emcli工具:

  1. 下载和安装最新的Java 1.6.x
  2. 下载emclikit.jar https://emcc_host:emcc_port/em/faces/core-emcli-emcliDownload
  3. 安装:java -jar emcliadvancedkit.jar -install_dir=<em_cli_home_dir>
  4. 配置:/u01/app/oracle/emcli/emcli setup -url=https://192.168.56.241:7802/em/ -username=SYSMAN

使用以下命令,登陆emcli并导入catalog:

4、再次检查“ Self Update (自行更新)”配置页:

EMCC01

此时可以看到,虽然仍然是在Offline模式下,但是已更新catalog内容,可以看到Agent Software有50个Available Updates。

5、点击”Agent Software “,进入agnet列表,选择所需的agent,然后点击”Download”:

EMCC02

然后使用emcli导入agent软件:

6、再次检查“ Self Update (自行更新)”配置页,可以看到新的agent已经下载完毕: EMCC03 点击”Apply”使之可以给部署使用。此时会有一个后台作业呗创建,在几秒之后,可以看到状态被改变为”applied”。EMCC04

此时我们就可以开始部署此平台。
参考文档:

http://docs.oracle.com/cd/E24628_01/install.121/e22624/install_agent.htm#EMBSC292

RAC环境下SYSDATE返回错误时间

某客户反馈说,在11.2.0.3的RAC下,使用sqlplus连接时查询sysdate返回的时间是正确的,但是使用PL/SQL等通过Listener方式连接的时候,则返回错误的时间。

其实造成这个问题的原因是11.2.0.2后的新特性:

11.2.0.1的时候TZ变量取决于grid和root用户的shell环境变量TZ。

但是从11.2.0.2开始,Oracle的集群(GI)开始拥有自己的时区和配置,即TZ参数存在$GRID_HOME/crs/install/s_crsconfig_<nodename>_env.txt中设置的time zone。

一般集群的时区是在安装GI时从系统获取的。经过沟通后,客户确实在前段时间更改过系统时区,至此造成的sysdate返回错误的原因就是因为当操作系统的时区发生改变时,但是GI的时区未改变。解决方:修改TZ值,重启节点。

具体修改可以参考MOS:How To Change Timezone for 11gR2 Grid Infrastructure (Doc ID 1209444.1)

行链接和行迁移

众所周知造成Oracle数据库性能低下的原因有很多,但是行链接和行迁移也很可能是其中原因之一。

 什么是行链接和行迁移?

1)该行太大,在它第一次插入时,无法放入一个数据块。

在行链接中,Oracle数据库将数据存储在为段保留的一个或多个被链接的数据块中。行链接最经常出现在大行中。例如包括包含LONG或LONG RAW数据类型列的行,或在2KB块中的VARCHAR2(4000)列,或具有大量列的行。在这些情况下出现链接行是不可避免的。

2)原先的行本来可以放入到一个数据块的,但是在更新后整体行长增加了,又没有足够可用空间来容纳更新的行。

在行迁移中,假设行可以容纳在一个新块中,Oracle数据库将会把整个行移动到一个新的数据块。原来的被迁移走的行块会包含一个指针或“转发地址”指向迁移到新块中的行。已迁移行的rowid不会改变。

3)超过255个列的行。

Oracle数据库在一个块行中只可以存储255的列。因此,如果你在具有1000个列的表中插入行,则数据库将创建4个快行,通常会链接多个块。

那么到底什么是行链接和行迁移呢?

行链接

如下图描述:向数据块中插入大行,行出入左边的块太大,所以数据库通过将第一个行块(row piece)放在左边的块,而将第二个行块(row piece)放入到右边的块中,这样就形成了行链接。

cncpt316

 

行迁移

如下图所示:左边的块包含的行被更新,但现在导致该行太大而不能放入块中。数据库将整个行移动到右边的块中,并在左边的块中保留一个指向被迁移行的指针。

cncpt306

根据上述概念总结:行链接一般发生在insert阶段(因数据块无法容纳过大数据);行迁移一般发生在update阶段(原数据块无法容纳增长的数据)

当行被链接或迁移时,检索数据所需的I/O灰增加。导致这种情况是因为Oracle数据库必须扫描更多块以检索行信息。例如,如果数据库执行一个I/O读取索引或者读取一个未迁移的表行,则需要额外的I/O才能获取迁移的数据行。

参考文档:
Chained and Migrated Rows
http://docs.oracle.com/cd/E11882_01/server.112/e40540/logical.htm#CNCPT1055

 

AWR 故障

无法获取AWR


造成无法获取AWR的原因,可能是未开启收集有关系。
确定是否开启
查询AWR当前配置信息
col SNAP_INTERVAL for a20
col RETENTION for a20
select * from dba_hist_wr_control;
      DBID SNAP_INTERVAL        RETENTION            TOPNSQL
———- ——————– ——————– ———-
2197530720 +00000 01:00:00.0    +00008 00:00:00.0    DEFAULT

检查是否启动基线
SQL> show parameter statistics_level
如果 STATISTICS_LEVEL=TYPICAL  或 ALL,则默认启用基线。

AWR开头显示:

WARNING: Since the DB Time is less than one second, there was minimal foreground activity in the snapshot period. Some of the percentage values will be invalid.
alter system set control_management_pack_access=”DIAGNOSTIC+TUNING” scope=both;
SQL> show parameter control_management_pack_access
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_management_pack_access       string      NONE
SQL> alter system set control_management_pack_access=”DIAGNOSTIC+TUNING” scope=both;
System altered.
SQL> show parameter control_management_pack_access
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_management_pack_access       string      DIAGNOSTIC+TUNING
由于默认是每小时才生产一份AWR数据,所以等待一个小时或更长时间后在看看。

在分析数据库性能的时候,突然发现awr不完整,
重新生成AWR,发现如下错误:
ERROR:
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at “SYS.DBMS_WORKLOAD_REPOSITORY”, line 919
ORA-06512: at line 1
–数据库版本
SQL> SELECT * FROM V$VERSION;

BANNER
——————————————————————————
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
PL/SQL Release 11.2.0.3.0 – Production
CORE    11.2.0.3.0      Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 – Production
NLSRTL Version 11.2.0.3.0 – Production

–设置errorstack
alter session set events ‘6502 trace name errorstack level 12’;
—获取trace name
oradebug setmypid
oradebug tracefile_name
分析错误:
—– Error Stack Dump —–
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
—– Current SQL Statement for this session (sql_id=572fbaj0fdw2b) —–
select output from table(dbms_workload_repository.awr_report_html( :dbid,
                                                            :inst_num,
                                                            :bid, :eid,
                                                            :rpt_options ))
—– PL/SQL Stack —–
—– PL/SQL Call Stack —–
  object      line  object
  handle    number  name
7000011f4948398       919  package body SYS.DBMS_WORKLOAD_REPOSITORY
700001222708fd0         1  anonymous block
—– Call Stack Trace —–
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
——————– ——– ——————– —————————-
skdstdst()+40        bl       107c66680            FFFFFFFFFFF0320 ? 000000001 ?
                                                   00000000C ? 000000000 ?
                                                   000000000 ? 000000001 ?
                                                   00000000C ? 000000000 ?
ksedst1()+112        call     skdstdst()           FFFFFFFFFFF03F8 ? 000002004 ?
                                                   110A5E8C0 ? 10A6D12F4 ?
                                                   10A6D0848 ? FFFFFFFFFFF0720 ?
                                                   FFFFFFFFFFF0500 ? 110A5E8C0 ?
ksedst()+40          call     ksedst1()            10A6D12E8 ? 7000000000282 ?
                                                   10A6D12BC ? B000000000000 ?
                                                   10A6D0848 ? 000000000 ?
                                                   E800000000 ? 1974B073CFBD6 ?
dbkedDefDump()+1516  call     ksedst()             000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000003 ? 00000FA50 ?
                                                   000000000 ? 000000000 ?
ksedmp()+72          call     dbkedDefDump()       C06471240 ? 000000000 ?
                                                   10ABE01D8 ? 110D5AC08 ?
                                                   10ABE01D8 ? 110A5E8C0 ?
……
这是11.2.0.3上的bug,已经在12.1和11.2.0.3.3上修复
Bug 13527323 : AWR REPORT GENERATION COULD FAIL WITH ORA-6502 WITH MULTIBYTE CHARS IN SQL TEXT
Bug 13527323 – ORA-6502 generating HTML AWR report using awrrpt.sql in Multibyte characterset database (文档 ID 13527323.8)
解决方法:
1、(未验证)
update WRH$_SQLTEXT set sql_text = SUBSTR(sql_text, 1, 1000);
commit;
2、(推荐)升级到11.2.0.3.3以上版本

Oracle中的回收站(Recycle Bin)

什么是Recycle Bin
回收站(Recycle Bin)实际上是包含删除对象信息的数据字典表。删除表和其他相关对象,比如索引、约束和嵌套表,实际上没有被真的删除,还是继续占用空间。直到被从回收站中purged出去,才能从数据库释放相关的表空间的空间。
每个用户可以拥有自己的回收站,当然除非用户拥有SYSDBA权限,否则默认都只可以访问用户所属的回收站。
可以通过下列语句,查看在回收站中自己的对象:
select * from recyclebin;
特别需要注意的是:在sys下drop的表是不记录recyclebin的。

 

闪回删除和回收站的关系
recyclebin1
使用Flashback Table命令,可以在无需使用时间点恢复的情况下,还原drop table语句的结果。
由初始化参数REECYCLEBIN用于控制闪回删除功能是打开(on)还是关闭(off)。如果是off,则删除的表不会进入回收站。如果是on,则删除的表将进入回收站,并且可能可以恢复(取决于是否还被保留)。默认情况下,不管10g和11g中。RECYCLEBIN设置为ON。

 

recyclebin2
如果不启用回收站,则删除表时,与该表及其从属对象关联的空间会立即变为可回收。
如果启用了回收站,则删除表时,与该表及其从属对象管理的空间不会立即变为可回收。即使该空间确实显示在dba_free_space中。相反,会在回收站中引用删除的对象,这些对象仍属于其各自的所有者。在空间不紧张时,绝不会把回收站对象使用的快乐自动回收。从而可以尽可能长的期限内恢复回收站的对象。

 

回收站中对象的命名
将删除的表“移动”到回收站时,将使用系统生成的名称对该表机器关联对象和约束条件进行重命名。
这样做的好处是避免以下情况:
用户删除表后,又用相同的名重建,又再删除。
两个用户使用相同的表名,但又都删除这些表。
重命名惯例如下:BIN$unique_id$version。
其中unique_id是该对象的全局唯一标识符,包含26个字符,用于在所有数据库之间的唯一的标识回收站名称。
而version是数据库分配的版本号。

 

回收站:自动回收空间
recyclebin3
只要回收站对象使用的空间没有被回收,就可以使用闪回删除功能恢复这些对象。
下面是回收站对象的回收策略:
显式发出purge命令时执行手动清理
空间不足时执行自动清除:对象在回收站中时,DBA_FREE_SPACE也会报告其对应的空间,因为这些空间是可以自动回收的。然后按以下顺序使用特定表空间中的空闲空间:
1.与回收站对象不对应的空闲空间
2.与回收站对象对应的空闲空间。在这种情况下,将使用先进先出(FIFO)算法自动将回收站对象从回收站清理
3.自动分配的空闲空间。

 

回收站管理

启停回收站
停用回收站
ALTER SESSION SET recyclebin = OFF;
ALTER SYSTEM SET recyclebin = OFF SCOPE = SPFILE;
启用回收站
ALTER SESSION SET recyclebin = ON;
ALTER SYSTEM SET recyclebin = ON SCOPE = SPFILE;
注意:上述操作都需要重启数据库生效。

 

查看和查询回收站中的对象
试图 描述
USER_RECYCLEBIN 用户查看回收站中自身删除的对象,也可用通过同义词recyclebin查看。
DBA_RECYCLEBIN 管理员查看回收站中所有的删除对象。

 

查看回收站中中的对象
select original_name, object_name, ts_name, droptime from dba_recyclebin
SQL> show recyclebin  –不显示索引
ORIGINAL NAME    RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
—————- —————————— ———— ——————-
PP               BIN$9dV9fqwIE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:30:15
PP               BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:16:25
PP               BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 TABLE        2014-03-30:23:21:34
查询回收站中的对象,但是必须要用””指定正确回收站中的对象名
SQL> select * from “BIN$9dV9fqwGE+TgQwEAAH/i4w==$0”;

 

回收站:手动回收空间
使用PURGE命令可从回收站中永久地删除对象。从回收站中清除某个对象时,会从数据库中永久地删除该对象及其从属对象。因此,将无法再使用闪回删除功能恢复从回收站中清除的对象。
下面是可能使用的一些PURGE命令:
清除指定表和索引
PURGE {TABLE <table_name>|INDEX <index_name>}
示范:
purge table “BIN$9dV9fqwGE+TgQwEAAH/i4w==$0”;
purge table table_name;
purge index index_name;
清除驻留在指定表空间中的所有对象(也可能清楚从属、驻留在其它表空间中的对象)
PURGE TABLESPACE <ts_name> [USER <user_name>]
示范:
purge tablespace test;
purge tablespace test user z;
清除属于当前用户的所有对象或者清除所有对象(dba_recyclenbin,必须具有足够的系统权限或者sysdba权限)
PURGE [USER_|DBA_]RECYCLEBIN

 

不使用回收站
drop table <table_name> [purge];
表空间中的对象不会移到回收站中,且回收站中所属该表空间的对象也会被清理。
drop tablespace <ts_name> [including contents]
从数据库中永久地删除该用户及其拥有的所有对象。且回收站中所属的已删除用户的所有对象都将被清理。
drop user <user_name> [cascade]

 

从回收站回复表
使用flashback table…to before drop语句从回收站恢复对象。你可以指点回收站中的对象名,也可以指定原始表名。
rename to子句选项可以使恢复的时候重命名。
语法:
FLASHBACK TABLE <table_name> TO BEFORE DROP
[RENAME TO <new_name>];
示范:
在恢复前,先查询,所需要的信息
SQL> show recyclebin
ORIGINAL NAME    RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
—————- —————————— ———— ——————-
PP               BIN$9dV9fqwIE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:30:15
PP               BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 TABLE        2014-03-31:00:16:25
PP               BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 TABLE        2014-03-30:23:21:34
或者
SQL> select object_name, original_name, createtime from recyclebin;
OBJECT_NAME                    ORIGINAL_NAME                    CREATETIME
—————————— ——————————– ——————-
BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 PP                               2014-03-31:00:16:19
BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 PP                               2014-03-30:23:21:28
BIN$9dV9fqwIE+TgQwEAAH/i4w==$0 PP                               2014-03-31:00:30:13
使用如下命令恢复表:
flashback table pp to before drop rename to zzz;
SQL> select object_name, original_name, createtime from recyclebin; 

OBJECT_NAME                    ORIGINAL_NAME                    CREATETIME
—————————— ——————————– ——————-
BIN$9dV9fqwHE+TgQwEAAH/i4w==$0 PP                               2014-03-31:00:16:19
BIN$9dV9fqwGE+TgQwEAAH/i4w==$0 PP                               2014-03-30:23:21:28

我们可以看出,恢复的表是最后被删除的,但是这个表不是我们实际需要的,怎么办?
还可以使用回收站中的对象名:
flashback table “BIN$9dV9fqwGE+TgQwEAAH/i4w==$0” to before drop;

 

恢复依赖对象
注意:恢复删除的表时,恢复的索引、触发器和约束条件将保留各自的回收站名称。因此,建议在闪回删除表前查询回收站和DBA_CONSTRAINTS。
1、在闪回之前,必须要先查询好表的相关信息
SQL>  select object_name, original_name, createtime from recyclebin;
OBJECT_NAME                    ORIGINAL_NAME                    CREATETIME
—————————— ——————————– ——————-
BIN$9daqMpoEFoLgQwEAAH/mBQ==$0 IDX_PPP_02                       2014-03-31:00:45:01
BIN$9daqMpoFFoLgQwEAAH/mBQ==$0 IDX_PPP_01                       2014-03-31:00:45:14
BIN$9daqMpoGFoLgQwEAAH/mBQ==$0 PP                               2014-03-31:00:44:32
2、恢复表
SQL> flashback table pp to before drop;
3、查询在回收站中恢复表对应关联对象
SQL> select index_name from user_indexes where table_name=’PP’;
INDEX_NAME
——————————
BIN$9daqMpoFFoLgQwEAAH/mBQ==$0
BIN$9daqMpoEFoLgQwEAAH/mBQ==$0
4、重命名到正确的对象名
alter index “BIN$9daqMpoFFoLgQwEAAH/mBQ==$0” rename to IDX_PPP_01;
alter index “BIN$9daqMpoEFoLgQwEAAH/mBQ==$0” rename to IDX_PPP_02;

 

Oracle Parallel Execution(Oracle的并行执行)

并行执行就是同时开启多个进程/线程来完成同一个任务,并行执行的每个进程/线程都会消耗额外的硬件资源,所以并行执行的本质就是以额外的硬件资源消耗来换取执行时间的缩短。说白了就是把一个大任务拆分为多个小的子任务,并把该任务的执行方式由一个单进程/线程依次执行改成由多个进程/线程同时并发执行,而且每个子进程/线程只执行拆分后的子任务。
开启并行执行的几种方法:
会话级:
alter session force parallel dml;
alter session enable parallel ddl;
alter session disable parallel dml;
语句级:
alter session force parallel query parallel 2;
alter session disable parallel query;
对象级:
alter table t1 noparallel;
alter index idx_t1 parallel 3;

Oracle中的并行执行操作 

在所有的操作中,并行度,取决于当前系统的Idle,切勿盲目使用!
1、并行查询
典型的查询如:全表扫描、快速索引全扫描、分区索引范围扫描,或者全部扫描的表连接(包括hash join、排序合并连接和嵌套循环连接)。
需要满足以下任意条件:
(1) SQL语句中有hint提示,比如parallel或parallel_index
(2) SQL语句中的对象呗设置了并行属性(DEGREE)
如:select  /*+parallel(t1 2) */ * from t1;
2、并行DDL
典型的DDL语句如下:create table   as select,create index,rebulid index,rebuild index partition,move/split/coalesce partition。这些语句如果并行执行,通常情况下都可以缩短执行时间。
示例:
但是必须要注意的是:在并行执行完DDL语句后,可能会导致相关的对象默认并行度的变化
使用并行创建后的并行度会有1变成DEFAULT。
DEFAULT的值:
    For a single instance, DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT
    For an Oracle RAC configuration, DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT
这意味着以后在访问索引IDX_T2时,CBO可能会考虑并行执行。这可能会引发一些问题,所以在并行执行完DDL语句后,通常应调整其并行度为1;
alter index idx_t2 noparallel;
这里特别需要注意的是,create table的时候却并不会修改其并行:
3、并行DML
Oracle中的一些DML语句也是可以并行执行的,比如:insert   as select、update、delete和merge。也一样可以达到缩短执行时间的效果。
这里需要注意的是,真正并行执行需要使用alter session force parallel dml或者使用alter session enable parallel dml和加并行hint的DML联合使用。

启用并行hint后执行上述更新操作后发现执行时间反而更长。

简单的对比下SQL的执行:

实际并行只发现在扫描表T2上,真正的更新操作并没有并行执行。

那么怎么样才能是DML语句可以使用并行执行呢?
alter session force parallel dml;
如果出现:
ERROR: 

ORA-12841: Cannot alter the session parallel DML state within a transaction
则是因为,刚刚有执行过的语句还未commit或rollback,只需要commit或者rollback即可。
存储过程可以使用:
IF …
THEN COMMIT;
END IF;
or
IF …
THEN …
ELSE
ROLLBACK;
END IF;
再次执行:
21:37:58 SQL> alter session force parallel dml;
Session altered.
Elapsed: 00:00:00.00
21:38:04 SQL> update t1 set username=’z’;
6120 rows updated.
Elapsed: 00:00:00.16
明显可以看出执行时间的缩短。
上述并行更新的执行计划为:
可以看到,上述更新操作是真正并行执行的,并行部分不仅发生在全表扫描T1部分,而且也发生在更新部分。
除了上述的alter session force parallel dml之外,还可以使用alter session enable parallel dml和加并行hint的DML联合使用也同样可以达到真正并行执行DML操作。这里特别需要注意的是仅仅修改表的并行度和仅使用并行hint,都不能真正并行执行DML。
4、并行数据加载
SQL*Loader导入文本数据,针对同一个表,使用DIRECT方式和并行导入,如下所示:
sqlldr userid=user/pwd control=load1.ctl direct=true parallel=true
sqlldr userid=user/pwd control=load2.ctl direct=true parallel=true
这里启用2个会话,同时并行执行对同一个表的导入。当然源数据得手工拆分成两份。
指定加载:
sqlldr userid=user/pwd control=load1.ctl direct=true
指定并行和加载:
sqlldr userid=user/pwd control=load2.ctl direct=true parallel=true
5、并行收集统计信息
在使用DBMS_STATS包收集统计信息时指定相应的并行执行,可以一定程度上缓解统计信息收集时间过长的问题,实际上这也是DBMS_STATS包比analyze命令的强大之处。
如:exec DBMS_STATS.GATHER_TABLE_STATS(ownname=>’Z’,tabname=>’T1′,ESTIMATE_PERCENT=>5,method_opt=>’for all columns size 1′,cascade=>true,force=>true,degree=>8);
这里特别要注意的是,degree值取决于系统的idle,切勿盲目的。

验证 set autotrace查看DML语句的执行计划会被实际执行

很多时候我们总是喜欢使用set autotrace on、set autotrace traceonly和set autotrace traceonly explain这种方式来查看目标SQL的执行计划,但是你知道吗?autotrace方式查看执行计划,如果目标SQL是DML语句会被实际执行。
先测试select 


通过上述,可以证明在 set autotrace 语句执行select不会实际执行。

我们在来看下当使用set autorace on时,执行DML语句会怎么样?


可以看出,DML语句已经被实际执行。

继续接着上述实验,我们看下set autotrace traceonly时,执行insert会怎么样?

同样也可以看到insert语句也被实际执行了。

我们再来验证下set autotrace traconly explain查看DML语句的执行计划是否会被实际执行:

同样我们可以看到DML语句已被实际执行。

从上述的例子我们可以看出使用set autotrace后执行DML语句,该DML会被实际执行。所以在使用set autotrace来获取DML语句的执行计划时要特别小心,因为这些DML会被实际执行。

12c New Features:使用RMAN连接CDB


Making RMAN Connections to a CDB
本节描述在12c中如何使用RMAN客户端连接CDB和PDB。它包含以下主题:
  • 关于CDBs的备份和恢复
  • 限制连接到PDB(Restrictions When Connected to a PDB)
  • 连接Root为目标(Connecting as Target to the Root)
  • 连接PDB为目标(Connecting as Target to a PDB)
关于CDBs的备份和恢复
你可以对整个CDB、只有root、单个或多个PDB执行RMAN操作。你可以根据以下规则让RMAN连接CDBs:
  • 在整个CDB上执行操作(例如,备份整个CDB)你需要连接到root作为目标。
  • 只对root执行操作(例如,备份root)你需要连接到root作为目标。
  • 对单个PDB执行操作,你可以连接到root或直接的连接PDB作为目标
    • 如果你通过root连接,必须使用PLUGGABLE DATABASE语法使用RMAN命令。例如,备份一个PDB,可以用BACKUP PLUGGABLE DATABASE命令
    • 如果你是直接连接到一个PDB,你可以使用和连接到非CDB一样的命令。例如,备份一个PDB,你可以使用BACKUP DATABASE命令。
  • 通过一个命令在两个或更多的PDBs上执行操作,你需要连接到root作为目标。例如,备份sales和hr的PDB,你可以连接到root,然后提交以下命令:BACKUP PLUGGABLE DATABASE sales,hr;
注意:如果你连接CDB为目标是通过操作系统认证,你就是连接为root。
限制连接到PDB(Restrictions When Connected to a PDB)
当你是直接连接PDB为目标,以下操作是不允许:
  • 备份archive logs
  • 删除archive logs
  • 删除archive logs备份
  • 恢复归档日志(RMAN在media recovery期间需要恢复archived logs)
  • 时间点恢复 Point-in-time recovery (PITR)
  • 表空间时间点恢复(TSPITR,Tablespace Point-in-time Recovery)
  • 表恢复 Table recovery
  • 副本数据库 Duplicate database
  • 闪回操作 Flashback operations
  • 运行数据恢复指导 Running Data Recovery Advisor
  • Report/delete obsolete
  • Register database
  • Import catalog
  • Reset database
  • 配置RMAN环境(使用CONFIGURE命令)
注意:当你连接目录为PDB,你不能连接到恢复目录(recovery catalog)
连接Root为目标(Connecting as Target to the Root)
有多种方法可以连接到root作为目标,以下三个是最常见的方法:
  • 通过普通用户本地连接(Connecting locally as a common user)
  • 通过操作系统认证连接( Connecting with operating system authentication)
  • 普通用户通过Oracle Net Services使用网络服务名连接
在所有的情况下,你连接的用户必须要有SYSDBA货SYSBACKUP权限。
例1使用SYS用户在本地连接到root,这是一个常见的用户,建立连接使用的是SYSDBA权限
例1: Connecting Locally to the Root
[oracle@db12c ~]$ rman target sys
connected to target database: DB12C (DBID=1279217785)
RMAN>
例2: Connecting to the Root with Operating System Authentication
[oracle@db12c ~]$ rman target /
connected to target database: DB12C (DBID=1279217785)
例3:Connecting to the Root with a Net Service Name
rman target c##bkuser@sales
target database Password: password
connected to target database: CDB (DBID=659628168)
连接PDB为目标(Connecting as Target to a PDB)
连接到一个PDB作为目标,你必须:
  • 连接到一个网络服务名称必须解析PDB的数据库服务。
  • 连接到拥有SYSDBA权限的一个本地用户或公共用户
  • 你想要执行RMAN操作的PDB名称
  • 解析对应的网络服务名到对应的PDB数据库服务
  • 在hrpdb PDB上创建对应的local user hrbkup并且授予sysdba权限。
例4:Connecting As Target to a PDB
rman target hrbkup@hrpdb
target database Password: password
connected to target database: CDB (DBID=659628168)

12c New Features:备份CDBs和PDBs


关于备份CDBs和PDBs
在12c中RMAN和Oracle Enterprise Manager Cloud Control对多租户环境提供完整的备份和恢复支持。多租户体系结构能够使一个Oracle Database作为CDB功能。你可以对整个CDB、或仅仅root、一个或多个PDB做备份和恢复。你也可以在PDB中的单个表空间和数据文件做备份和恢复。
你可能想要通过使用增量备份策略在夜间执行备份整个CDB,或者你可能想要经常对个别PDB进行备份和很少对整个CDB或者root做备份。
从对数据丢失的恢复能力,单独备份root和所有的PDB等同于备份整个CDB。两者的主要区别是在你输入RMAN命令的数量和恢复时间。恢复整个CDB比恢复root加上所有的PDB需要的时间更少。
备份整个CDB
备份整个CDB和备份非CDB类似,但你备份整个CDB,RMAN会备份root和所有的PDB,还有archived redo logs。你可以从CDB备份中恢复整个CDB,或只有root,一个或多个PDB。
备份整个CDB
按照说明在“Backing Up a Whole Database with RMAN”,使用有sysbackup或sysdba权限的公共用户(common user)连接root。
使用RMAN备份Root
你可以使用RMAN只针对root做备份。因为在整个CDB中root包含关键元数据。Oracle推荐定时备份root或备份整个CDB。
使用RMAN备份root:
  1. 启动RMAN并且使用有SYSBACKUP或SYSDBA权限的共有用户(common user)连接到root。
  2. 输入下面的命令:BACKUP DATABASE ROOT;
使用RMAN备份PDBs
RMAN可以支持对CDB中的一个或多个PDBs备份。有两种方法使用RMAN来备份PDB:
  • 连接到root和使用BACKUP PLUGGABLE DATABASE命令,这种方法能够使用一个命令备份多个PDB。

当你连接到一个PDB使用root,这种备份只对root和特定的PDB,而且不是其他的PDBs。

  • 连接到PDB和使用BACKUP DATABASE命令。这种方法只备份单一的PDB,而且你也可以使用相同的命令来备份non_CDB。

创建备份的时候,通过root连接,则可以连接到任意可见的PDB。

当你备份单独的PDB,archived redo log是不会被备份的。
连接到root备份一个或多个PDB:
  1. 启动RMAN并且使用有SYSBACKUP或SYSDBA权限的共有用户(common user)连接到root。
  2. 在RMAN提示符里发送BACKUP PLUGGABLE DATABASE命令。

 

连接到PDB备份单个PDB:

  1. 启动RMAN并且使用有SYSBACKUP或SYSDBA权限的本地用户(local user)连接到PDB。
  2. 在RMAN提示符里发送BACKUP DATABASE命令。
备份在PDB中的表空间和数据文件
因为表空间在不同的PDB中可以有相同的名字,为了消除歧义,你必须直接的连接到PDB来备份一个或多个表空间。相比之下,因为数据文件的序号(numbers)和路径(paths)在CDB中是独一无二的,你可以连接到root或者PDB来备份PDB的数据文件。如果你连接到root,你可以使用一条命令来备份多个PDB的数据文件。如果你连接到PDB,你只能可以备份这个PDB的数据文件。
备份PDB中的表空间:
  1. 启动RMAN并且使用有SYSBACKUP或SYSDBA权限的本地用户(local user)连接到PDB。
  2. 发送 BACKUP TABLESPACE命令,详细描述参看 “Backing Up Tablespaces and Data Files with RMAN”

备份PDB中的数据文件:
  1. 执行下列操作之一:
  • 启动RMAN并且使用有SYSBACKUP或SYSDBA权限的共有用户(common user)连接到root。
  • 启动RMAN并且使用有SYSBACKUP或SYSDBA权限的本地用户(local user)连接到PDB。
 2. 发送BACKUP DATAFILE命令。

 

ORA-00845: MEMORY_TARGET not supported on this system

最近在玩12c,在Oracle Linux 6.3上搭一个单实例带grid,在DBCA建库的时候出现:

或者在启动数据库的时候:

接着建库中止,仔细研究后发现,造成这个问题是由于设置SGA的大小超过系统的/dev/shm的大小:


查看alert_orcl.log日志,找到如下报错:

看到日志中:
当前大小:1415770112 bytes  =1350.1834 MB

期望大小: at least 1644167168 bytes  = 1568 MB

一般来说,shm默认大小是系统内存的1/2大小。即系统内存是4G,则tmpfs就是2G。你可能会说既然期望是1568MB,2G也足够了,这里不能忘记还有ASM实例又会占用一些内存,剩下的就小于1568m了。

方法1:调低MEMORY_TARGET内存

alter system set MEMORY_MAX_TARGET=1G scope=spfile;

当然如果已经无法启动库,也没法操作上述命令。而且对于真实应用调低MEMORY_TARGET内存也不是很实用。具体方法就不示范,以方法2为主。

方法2:修改shm容量


发现shm也在被Grid进程正在使用,为了umount该装载点,必须先得shutdown ASM instance

如果有数据库则先关闭数据库

再次查看



这时候不妨把值给的更大一点,因为还有ASM实例会需要占用一部分。

或者也可以直接

但是请注意,以上方法在OL6.3中,哪怕是修改/etc/fstab,重启机器后也还是会变成默认。实测在5.8的版本中修改/etc/fstab应该是直接生效的。

所以需要在开机后马上执行下:mount -o remount /dev/shm

或者一劳永逸的方法

使用暴力方法,在开机的过程中remount。(强烈推荐

增加红色部分:

———————————————

也可以通过/etc/rc.d/rc.sysinit使fstab中tmpfs的修改生效

注释如下语句

#mount -f /dev/shm >/dev/null2>&1

在rc.syinit中找到如下内容:

在如下部分里添加tmpfs这个类型:

 方法3: