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:

 

Not All Endpoints Registered

 

在新的机器上搭建一个11g R2的单实例测试环境,为了图快速,直接复制原来做好的虚拟机模板。

在安装完毕后,dbca建库的时候,在Specify ASMSNMP password specific to ASM:的时候输入正确的密码后监听报错:

Could not validate  ASMSNMP Password due to following error -“ORA-12514:TNS:监听程序当前无法识别连接描述符中请求服务”.Do  you want  to continue ? If you continue ,ASM will not  be configured to be monitored by Database Control.

检查服务

发现listener的状态是INTERMEDIATE,而且STATE_DETAILS是显示为Not All Endpoints Registered。

查看监听状态

查找了无数的资料,及MOS:Listener in INTERMEDIATE status with “Not All Endpoints Registered” [ID 1454439.1]

因为这是单实例,按照此方法,也无问题。后来又重建监听等一系列动作,还是如此。

最后想到因为这是复制过来的虚拟机模板,只改了机器名,还没有修改hosts。

果然修改hosts后,重启监听,一切都OK了。

谨以此文:铭记本人的粗心、急躁、无耐心,不谨慎

铭记:作为DBA,一定要仔细小心耐心

Tuning the Shared Pool的基本概念

这是一篇学习Performance Tuning——Tuning the Shared Pool的学习笔记,主要是基本的概念。

共享池体系结构

shared pool architecture

共享池的基本用途是充当元数据高速缓存。共享池多数是用来支持共享SQL和PL/SQL程序包的执行的。

共享池的主要组件包括:

  • 库高速缓存,它将共享的SQL和PL/SQL代码以及对象元数据存储在按名称空间进行区分的各个区域中
  • 数据字典高速缓存,它报错数据字典表中的 row images,又称row cache(行高速缓存)
  • 结果高速缓存(results cache)保存查询结果集和查询碎片,因此后续查询可直接从该高速缓存中检索结果

共享池中的空间分配由最近最少使用(LRU(least recently used))的算法进行管理。

Continue reading Tuning the Shared Pool的基本概念

Using Baseline

这是一篇学习baseline的笔记,主要讲述:基本的概念、使用sql创建和管理(删除),单一AWR基线、基线模板、修改默认的Moving Window Baselin的大小。

在 Oracle Database 11g 中,AWR基线提供了定义动态和未来基线的强大功能,并在很大程度上简化了创建和管理性能数据(以便比较)的过程。

Comparative Performance Analysis with AWR Baselines

Oracle Database 11g 默认具备一个系统定义的Moving Window Baseline,该基线对应于 AWR 保留期中的所有 AWR 数据。仅可存在一个Moving Window Baseline。系统定义的Moving Window Baseline认大小为当前的AWR保留期,即默认为八天。

如果要增大Moving Window Baseline,首先需要相应增大AWR保留期。AWR保留期和系统定义的Moving Window Baseline的大小是两个独立的参数。但是AWR保留期必须大于或等于系统定义的Moving Window Baseline的大小。

Oracle Database 11g 提供了收集两种基线的功能:静态基线和Moving Window Baseline。 静态基线可以是单一的,也可以是重复的。单一 AWR 基线是在单一时段内收集的。重复基线是在重复的时段(例如,六月份的每个星期一)内收集的。

在 Oracle Database 11g 中,如果 STATISTICS_LEVEL=TYPICAL 或 ALL,则默认启用基线。

基线视图

  • DBA_HIST_BASELINE:显示有关系统中所获取的基线的信息。对于每个基线,该视图显示完整的时间范围,以及该基线是否为默认基线。其它信息包括创建日期、上一次统计信息计算的时间和基线类型。
  • DBA_HIST_BASELINE_DETAILS:显示可用来确定给定基线有效性的信息,如基线时段期间是否存在关闭操作及基线时段中由快照数据覆盖的百分比。
  • DBA_HIST_BASELINE_TEMPLATE:保存了基线模板。该视图提供了 MMON 所需的信息,用以确定何时根据模板创建基线,以及何时应删除基线。
  • DBA_HIST_BASELINE_METADATA:显示基线的元数据信息,包括名称、类型、创建时间、模板和失效时间。

如果要在过去的某个时段创建基线,则使用 CREATE_BASELINE 过程;如果时段有任何部分处于未来,则使用 CREATE_BASELINE_TEMPLATE 过程。

Continue reading Using Baseline