Ubuntu x86_64安装oracle 11gR2 XE

25-04-22 9

以上就是给各位分享Ubuntux86_64安装oracle11gR2XE，同时本文还将给你拓展11GR2中的常见RMAN问题、11gR2新特性--待定的统计信息（PendingStatistic）、1

以上就是给各位分享Ubuntu x86_64安装oracle 11gR2 XE，同时本文还将给你拓展11GR2 中的常见 RMAN 问题、11gR2 新特性 -- 待定的统计信息（Pending Statistic）、11gR2 集群件任务角色分离（Job Role Separation）简介、apt-get update 失败 ubuntu:Tempory failure resolving 'cn.archive.ubuntu.com ubuntu等相关知识，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

Ubuntu x86_64安装oracle 11gR2 XE
11GR2 中的常见 RMAN 问题
11gR2 新特性 -- 待定的统计信息（Pending Statistic）
11gR2 集群件任务角色分离（Job Role Separation）简介
apt-get update 失败 ubuntu:Tempory failure resolving 'cn.archive.ubuntu.com ubuntu

Ubuntu x86_64安装oracle 11gR2 XE

Oracle 11gR2 XE（注意XE)是Oracle提供的精简版Oracle，拥有正式版的所有功能，对内存要求也不高。很遗憾的是，官方只提供了rpm安装包（适用于CentOS，Redhat，Fedora），并没有提供deb包。本文提供如何安装Oracle 11gR2 XE的步骤。

下载安装文件

http://www.oracle.com/technet...

rpm转deb

unzip oracle-xe-11.2.0-1.0.x86_64.rpm.zip
sudo apt-get install alien libaio1 unixodbc vim
sudo alien --scripts -d oracle-xe-11.2.0-1.0.x86_64.rpm

准备工作

chkconfig

The Red Hat based installer of Oracle XE 11gR2 relies on /sbin/chkconfig, which is not used in Ubuntu. The chkconfig package available for the current version of Ubuntu produces errors and my not be safe to use. Below is a simple trick to get around the problem and install Oracle XE successfully:

sudo nano /sbin/chkconfig

把下面内容贴进去

#!/bin/bash
# Oracle 11gR2 XE installer chkconfig hack for Ubuntu
file=/etc/init.d/oracle-xe
if [[ ! `tail -n1 $file | grep INIT` ]]; then
echo >> $file
echo ''### BEGIN INIT INFO'' >> $file
echo ''# Provides: OracleXE'' >> $file
echo ''# Required-Start: $remote_fs $syslog'' >> $file
echo ''# Required-Stop: $remote_fs $syslog'' >> $file
echo ''# Default-Start: 2 3 4 5'' >> $file
echo ''# Default-Stop: 0 1 6'' >> $file
echo ''# Short-Description: Oracle 11g Express Edition'' >> $file
echo ''### END INIT INFO'' >> $file
fi
update-rc.d oracle-xe defaults 80 01

执行：

sudo chmod 755 /sbin/chkconfig

内核参数

执行：

sudo nano /etc/sysctl.d/60-oracle.conf

把以下内容粘帖进去：

# Oracle 11g XE kernel parameters  
fs.file-max=6815744  
net.ipv4.ip_local_port_range=9000 65000  
kernel.sem=250 32000 100 128
kernel.shmmax=4163487744
net.core.rmem_default=262144
net.core.rmem_max=4194304
net.core.wmem_default=262144
net.core.wmem_max=1048576
fs.aio-max-nr=1048576

内核参数的配置和这篇文章是一样的：CentOS 6.4 x86_64安装oracle 11gR2

加载内核参数：

sudo service procps start

执行以下语句看看内核参数是否修改成功

sudo sysctl -q fs.file-max

如果返回结果是fs.file-max = 6815744就说明修改成功了。

swap空间保证2g

杂项

执行下面语句

sudo ln -s /usr/bin/awk /bin/awk 
sudo mkdir /var/lock/subsys 
sudo touch /var/lock/subsys/listener

/dev/shm

sudo rm -rf /dev/shm
sudo mkdir /dev/shm
sudo mount -t tmpfs shmfs -o size=2048m /dev/shm

这里的内存大小就是你的物理内存的大小<wrap hi>free -m</wrap>可以看到

The reason of doing all this is that on a Ubuntu system /dev/shm is just a link to /run/shm but Oracle requires to have a seperate /dev/shm mount point.

新建以下文件：

sudo nano /etc/rc2.d/S01shm_load

把以下内容贴进去

#!/bin/sh
case "$1" in
start) mkdir /var/lock/subsys 2>/dev/null
       touch /var/lock/subsys/listener
       rm /dev/shm 2>/dev/null
       mkdir /dev/shm 2>/dev/null
       mount -t tmpfs shmfs -o size=2048m /dev/shm ;;
*) echo error
   exit 1 ;;
esac

执行下面

sudo chmod 755 /etc/rc2.d/S01shm_load

这样就可以make the change permanent

安装

sudo dpkg --install oracle-xe_11.2.0-2_amd64.deb

sudo /etc/init.d/oracle-xe configure

配置xe管理权限端口，sys密码等

环境变量

执行下面语句，添加文件

sudo nano /etc/profile.d/oracle-xe.sh

把以下内容贴进去

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
export ORACLE_SID=XE
export NLS_LANG="`$ORACLE_HOME/bin/nls_lang.sh`"
export ORACLE_BASE=/u01/app/oracle
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export PATH=$ORACLE_HOME/bin:$PATH

执行下面，给予执行权限

sudo chmod 755 /etc/profile.d/oracle-xe.sh

启动

sudo service oracle-xe start

如何卸载

如果安装过程中遇到问题，或者就想卸载掉，执行下面语句

sudo -s
/etc/init.d/oracle-xe stop
ps -ef | grep oracle | grep -v grep | awk ''{print $2}'' | xargs kill
dpkg --purge oracle-xe
rm -r /u01
rm /etc/default/oracle-xe
update-rc.d -f oracle-xe remove

网页管理界面

Oracle XE和正式版一样提供了B/S管理端界面，访问地址是 http://localhost:PORT/apex/

第一次进入时，需要从管理员入口进去，新建一下workspace等才能正常使用，管理员入口是 http://localhost:PORT/apex/ap...

用户名是admin
密码就是前面输入的密码

进入后修改一下admin密码，然后慢慢探索吧

额外的配置

解决11g不导出空表的问题
提高oracle可用性

11GR2 中的常见 RMAN 问题

本文是Oracle support对11GR2 RMAN备份过程中的问题总结

11GR2 中的常见 RMAN 问题

11gR2 中少数几个结构更改对 RMAN 设置产生了广泛的影响

1. Snapshot/Backup（快照/备份）控制文件位置必须位于 RAC 环境中的共享位置。

在 11gR2 及更高版本号中，控制文件的备份在运行时不会持有 CF enqueue。

对于非 RAC 数据库，这不会造成不论什么影响。可是，对于 RAC数据库，因为在 11gR2 中控制文件备份机制发生了更改，集群中的不论什么实例都能够写入到 snapshot/backup（快照/备份）控制文件。因此，Snapshot（快照）控制文件须要对全部实例都可见。从 SQL*Plus 直接创建控制文件的备份时也存在这样的情况。

集群中的不论什么实例都能够写入到备份控制文件。

控制文件备份，即使使用 SQL“alter database backup controlfile...”。也必须在共享设备上创建备份。

Snapshot（快照）控制文件必须可由 RAC 数据库的全部节点訪问；假设 snapshot（快照）控制文件不在共享设备上，则在 RMAN备份获取控制文件的 snapshot（快照）时会引发错误。这适用于使用 SQL*Plus 备份控制文件和在非共享位置配置了控制文件自己主动备份的情况。

RMAN-00571: ========================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS =============
RMAN-00571: =========================================================
RMAN-03009: failure of resync command on default channel at 03/13/2012 10:19:41
ORA-00245: control file backup operation failed

解决方式是将 Snapshot/backup（快照/备份）控制文件位置更改到共享设备上。否则将会失败。并出现 ORA-245: control file backup operation failed。

提醒：Note 1472171.1 In RAC environment from 11.2 onwards Backup Or Snapshot controlfile needs to be in shared location 是针对此问题而公布的。

2. MMON 进程在结构发生变化之后自己主动进行控制文件备份

在 11GR2 之前的发行版中，更改数据库结构的每一个 DDL 命令都会创建一个控制文件自己主动备份。在 alert.log 中能够看到。运行每一个 DDL 命令之后都会有一条关于控制文件自己主动备份创建的消息。在同一时候进行多个结构更改时。这可能会导致严重的性能问题。

从 Oracle Database 11g 发行版 2 開始实施了 Controlfile Autobackup Deferral 功能。在应用的脚本中包括多个结构更改时（比如。加入表空间、变更表空间或数据文件的状态、加入新的联机重做日志、重命名文件等），RMAN 仅仅进行一次控制文件自己主动备份。在 11gR2 中。控制文件自己主动备份由 MMON 从属进程在结构更改后的几分钟时间内创建。这能够提升性能。因此，在对数据库的结构更改数分钟之后获取控制文件自己主动备份是正常行为。同一时候在 alert.log 中不显示有关控制文件自己主动备份创建的消息也是正常的。

负责怪份控制文件的 MMON 从属进程会产生包括了创建控制文件所需信息的跟踪文件并命名为：<SID>_m000_<OS_PID>.trc

3. 能够在磁盘上运行恢复区备份

在 11gR2 之前。仅仅能在磁带上运行 Flash Recovery Area（高速恢复区，简称 FRA）的备份。

从 11GR2 開始，能够在磁盘上运行 FRA备份。

BACKUP 命令中加入了“TO DESTINATION”子句。这个加入的选项可指定特定文件夹位置，以便备份到磁盘。该选项主要用于 BACKUP RECOVERY AREA 命令。假设启用了 BACKUP OPTIMIZATION，则 RMAN 仅跳过已存在于“TO DESTINATION”子句所指定文件夹位置中同样文件的备份。

RMAN> Backup recovery area TO DESTINATION ‘+DATA’;

11GR2 中影响 RMAN 稳定性的常见 BUG。

1. BUG 9877980: SR11.2.0.2CSHAR_FORCE - TRC - KKSLMARKLITERALBINDS

症状：

数据库版本号：11.2.0.2。CURSOR_SHARING 为 FORCE 或 SIMILAR

RMAN 备份失败。出现 ORA-01008，或者显示各种错误

DBGSQL: TARGET> select count(*) into :dbstate from v$parameter where lower(name) = ''_dummy_instance'' and upper(value) = ''TRUE''
DBGSQL: sqlcode = 1008
RMAN-00571: =========================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS ==============
RMAN-00571: =========================================================
ORA-01008: not all variables bound

或者

RMAN-00571: =====================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ============
RMAN-00571: =====================================================
RMAN-03002: failure of allocate command at 12/07/2011 00:38:14
ORA-03114: not connected to ORACLE

而且 alert.log 中显示

ORA-07445: exception encountered: core dump [kkslMarkLiteralBinds()+240] [SIGBUS] [ADDR:0x18222D0202020D29] [PC:0x1049E96D0] [Invalid address alignment] []
或者
ORA-07445: exception encountered: core dump [kkslpli()+212] [SIGSEGV] [ADDR:0xFFFFFFFF7A973288] [PC:0x1049FEE14] [Invalid permissions for mapped object] []

根本原因是 BUG 9877980。此 Bug 的修复包括在 11.2.0.3 中。

此 Bug 有one-off patch可用。

Workaround: 清空共享池

Ref:

Bug 9877980 - ORA-7445[kkslMarkLiteralBinds] / Assorted Errors on 11.2.0.2 if cursor sharing is enabled Note 9877980.8

Alert: Note 1472116.1 RMAN backup fails with Assorted Errors on 11.2.0.2 if cursor sharing is enabled

2. Bug 8482162: SNAPSHOT CONTROLFILE STILL NEED NOAC ON NFS MOUNT POINT

假设控制文件自己主动备份目标文件系统为 NFS，则要求使用“NOAC”选项装载该文件系统；否则将报错 ORA-27054

症状：

假设 snapshot（快照）控制文件定位到 NFS 文件系统而且不是使用选项“NOAC”装载的，则 RMAN 备份将失败，并出现 ORA-27054 错误。依据 Bug 5064356 的修复，假设运行的是 10.2.0.4.0 或更高版本号，则不再须要 NFS 装载点的 NOAC 选项。

可是。此修复似乎仅适用于特定文件类型。也就是：联机重做日志、归档重做日志、备份片（比如：RMAN）和跟踪文件。

Starting Control File and SPFILE Autobackup at 07-APR-12
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3009: failure of Control File and SPFILE Autobackup command on
ORA_DISK_1 channel at 04/07/2012 10:29:17
ORA-1580: error creating control backup file
/oracle/product/10.2.0/db_1/dbs/snapcf_COPA1.f
ORA-27054: NFS file system where the file is created or resides is not
mounted with correct options
Additional information: 3

在 alert.log 文件里

Starting control autobackup
WARNING:NFS file system /oracle/product mounted with incorrect options
WARNING:Expected NFS mount options:
rsize>=32768,wsize>=32768,hard, actimeo=0
Autobackup failed with following error
ORA-1580: error creating control backup file
/oracle/product/10.2.0/db_1/dbs/snapcf_COPA1.f
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 3

出现此问题是因为 Bug 8482162: SNAPSHOT CONTROLFILE STILL NEED NOAC ON NFS MOUNT POINT. 此 Bug 已在 11.2.0.2 中修复

Workaround:

1) 对于保存snapshot（快照）控制文件的 NFS 文件系统。使用 NOAC 选项装载。

或者

2) 将 snapshot（快照）控制文件的位置更改到非 NFS。

Ref: Bug 8482162 Snapshot controlfile still needs "noac" on NFS mount points (ORA-27054) Note 8482162.8

3. Bug 9577583: FALSE ORA-942 OR OTHER ERRORS WITH MULTIPLE SCHEMAS HAVING IDENTICAL OBJECTS

当 RMAN 文件夹数据库（catalog）保存了多个 RMAN 文件夹 schema（方案）时，文件夹数据库上将提醒出现错误 ORA-00942。

症状：
用户发现多个 ORA-942 错误
不论什么在多个 schema（方案）下有同名对象的数据库都可能会遇到此问题。

这是间歇性问题。无法重现。但会多次出现。
这是通用的 Bug，主要影响 RMAN 文件夹备份。影响 11.2.0.1，在 11.2.0.2 中已提供了修复。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03015: error occurred in stored script incremental_level0
RMAN-03002: failure of backup command at 06/25/2010 13:21:22
RMAN-06004: ORACLE error from recovery catalog database: ORA-00942: table or view does not exist
RMAN-06031: could not translate database keyword

Debug跟踪信息显示

DBGSQL: EXEC SQL AT RCVCAT begin dbms_rcvman . translateDatabase ; end ; [13:21:22.794]
DBGSQL: sqlcode=-942 [13:21:22.795]
DBGMISC: krmksqlerror called from file krmk.c, line 12649 [13:21:22.796]
DBGRCVMAN: ENTERING translateDatabase
DBGRCVMAN: ENTERING validateState
DBGRCVMAN: EXITING validateState validateState
DBGRCVMAN: OPENING cursor translateDatabase_c in translateDatabase
DBGMISC: krmicomp: error 6004 signalled during compilation [13:21:22.797]
DBGMISC: ENTERED krmkmrsr [13:21:22.797]

RMAN-06004: ORACLE error from recovery catalog database: ORA-00942: table or view does not exist
ORA-06512: at "CALYPP.DBMS_RCVMAN", line 4590
ORA-06512: at "CALYPP.DBMS_RCVMAN", line 16168
ORA-06512: at line 1
RMAN-06097: text of failing SQL statement: begin dbms_rcvman . translateDatabase ; end ;
RMAN-06099: error occurred in source file: krmk.pc, line: 7618
RMAN-06031: could not translate database keyword

解决方式：

应用针对 Bug 9577583 的 Patch 9577583

Ref: Note 9577583.8 False ORA-942 or other errors when multiple schemas have identical object names.

4. BUG 10635701 - BACKUP OF FRA CONSUMES 15GB OF PGA AND FAIL WITH ORA-4030

RMAN 在备份大量文件时。会因为消耗过多内存而失败，并出现 ORA-4030。错误出如今heap（堆）KSFQ，当中包括带有凝视“KSFQ Buffers”的块。

影响 11.2.0.1 和 11.2.0.2，已在 11.2.0.3 中修复

症状：

RMAN 跟踪信息显示下面 function（函数）中出错。

dbms_backup_restore.validationvalidate。带有相似下文的跟踪行：
krmxrpc - channel t1 kpurpc2 err=4030 db=target proc=SYS.DBMS_BACKUP_RESTORE.VALIDATIONVALIDATE

失败进程的调用堆栈：

kghalf <- ksfqbalo <- ksfqbcre <- ksfqxc <- ksfqxcrx <- ksfqxcre <- krbrvv

分配的内存为 KSFQ的 heap（堆）。当中 KSFQ heap（堆）包括带有凝视“KSFQ Buffers”的块。该信息会被转储到错误 ORA-4030 生成的跟踪文件里

下面文件里的错误： /cihcissdb028/dump01/oracle/dxls/udump/diag/rdbms/dxls/dxls/incident/incdir_68404/dxls_ora_27140_i68404.trc:

ORA-04030: out of process memory when trying to allocate 824492 bytes (pga heap,kco buffer)
ORA-04030: out of process memory when trying to allocate 1052684 bytes (KSFQ heap,KSFQ Buffers)

解决方式：

应用 Patch 10635701，这个问题没有办法绕过。

影响 11.2.0.1 和 11.2.0.2，已在 11.2.0.3 中包括修复。

Ref: Note 10635701.8 RMAN backup many files consumes lots of PGA / fails with ORA-4030

5. BUG 12370722 - CATUPGRD.SQL HANGS WITH ARCH ERROR ORA-600 [KRR_HIGHEST_SCN_TIM_8]

升级到 11.2.0.2 之后。归档进程持续引发 ORA_0600 [krr_highest_scn_tim_8]。升级之后在 11.2.0.2 中报错。影响升级，导致停机。解决方法是清除联机重做日志。此问题已在 11.2.0.3 中修复。

下面列出的 Bug。其症状相似于父 bug 12370722

    Bug 11872889: ORA-600: INTERNAL ERROR CODE, ARGUMENTS: [KRR_HIGHEST_SCN_TIM_8]

    Bug 12534566: DATABASE OPEN FAILED ORA-00600 [KRR_HIGHEST_SCN_TIM_8]

    Bug 11062394: ORA-600 [KRR_HIGHEST_SCN_TIM_8] REPORTED BY AN ARCHIVER PROCESS

全部这些 Bug 均已关闭。与下面 Bug 反复：

   Bug 12370722: CATUPGRD.SQL HANGS WITH ARCH ERROR ORA-600 [KRR_HIGHEST_SCN_TIM_8]

症状：

查找错误：
?运行 Oracle 版本号 11.2.0.2
?数据库最近从 10.2（或 10.1）升级到 11.2.0.2，为确认这一点。11.2.0.2 alert log 应显示“ALTER DATABASE OPEN MIGRATE”。

归档进程定期（比如每分钟）报错 ORA-00600:[krr_highest_scn_tim_8]。然后终止，调用堆栈例如以下：
-> ksbrdp -> krsv_abs -> ksbabs -> kcrrwk -> kcrrwkx -> krse_arc_driver -> krse_arc_driver_cor -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]

或者

尝试打开数据库的进程报错 ORA-00600:[krr_highest_scn_tim_8]。调用堆栈例如以下：
-> adbdrv -> kcfopd -> kcttsc -> krsq_arch_to_force_ -> krse_arc_driver -> krse_arc_driver_cor -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]

或者

运行 alter system archive log all; 的进程报错 ORA-00600:[krr_highest_scn_tim_8]。调用堆栈例如以下：

-> kkyasy -< krsq_arch_all_or_next -> krsq_arch_one_log -> krse_arc_driver->krse_arc_driver_core -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]
一个特定联机重做日志未归档，下面查询会显示未归档的日志序列号：

SQL> select sequence# from v$log where archived=''NO'' and status = ''CURRENT'';

错误：

RMAN-00571: =======================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: =======================================================
RMAN-03009: failure of sql command on default channel at 05/20/2011 01:26:24
RMAN-11003: failure during parse/execution of SQL statement: alter system archive log current
ORA-00600: internal error code, arguments: [krr_highest_scn_tim_8], [], [], [], [], [], [], [], [], [], []

Workaround:

为防止出现 ORA-00600:[krr_highest_scn_tim_8]，请在開始升级到 11.2.0.2 之后。不要返回并使用 Oracle 版本号 10 打开数据库。

假设数据库因为无法切换到下一个（未归档的）联机重做日志而挂起，或者因为前台进程尝试归档联机重做日志并出现 ORA-00600:[krr_highest_scn_tim_8] 错误而终止，导致无法打开数据库，则尝试加入还有一个重做日志组

SQL> startup mount

     alter database add logfile group <n> (''<filename>'') size <x>M;

假设已经报错 ORA-00600:[krr_highest_scn_tim_8]，而且定期持续报错，则能够通过下面方法之中的一个来解决：

- 安装补丁程序，

- 或者通过下面方法清除联机重做日志：

SQL> select group# from v$log

     where archived=''NO'' and status = ''CURRENT'';

     alter database clear logfile group <group#>;

注：清除联机重做日志表示该序列号的日志中的重做无法用于恢复。因此应该在清除日志之后尽可能早地运行完整备份。

6. BUG 10170431 - CTWR CONSUMING LOTS OF CPU CYCLES

假设启用了 Block Change Tracking（块更改跟踪，简称 BCT）。则 CTWR进程会消耗 CPU，而数据库总体性能将会受到严重影响。

这样的现象会在 11.2.0.2 中发生，解决方法是禁用块更改跟踪或应用one-off补丁程序。

该问题已在 11.2.0.3 中修复

症状：

在最低负载的情况下，CTWR 后台进程消耗 90% 到 100% 的 CPU。

ALTER SYSTEM CHECKPOINT 会显著减少 CTWR CPU 负载。稍后将返回到 90% 到 100% CPU 负载（CTWR处理块更改之后）。这样的现象非常有可能也是这个问题。

CTWR 的调用堆栈非常可能显示在下面函数中不断循环（spinning）：

kcmgtsf ()
krcptmo ()
ksbabs ()
krcpabs ()
ksbrdp ()

Workaround: 禁用 BLOCK CHANGE TRACKING (BCT) 或者应用针对 bug 10170431 的 Patch 10170431。

7. BUG 13000553 - RMAN BACKUP FAILS WITH RMAN-20999 ERROR AT STANDBY DATABASE

RMAN备份或者又一次同步RMAN文件夹（resync catalog）命令失败，出现错误RMAN-20052: invalid datafile create SCN

将数据文件加入到transportable表空间，然后恢复文件夹出现故障。

因为插入(plug in) SCN 为零。导致在尝试使用恢复文件夹时出现故障。

解决方法是应用 patch 13000553.

Bug 13877582 - RMAN SOME DATAFILES AT STANDBY SITE APPEAR WITH NULL NAME

发现与下面 Bug 反复：

Bug 13000553 - RMAN BACKUP FAILS WITH RMAN-20999 ERROR AT STANDBY DATABASE

症状：
目标数据库是 dataguard（物理备用）环境
表空间已插入(plug in)了主数据库。
插入(plug in)表空间之后，一些数据文件被加入到当中。
恢复文件夹为 11.2.0.3

已在下面版本号中修复：12.1

解决方式

在恢复文件夹数据库中应用 patch 13000553，并在主网站与备用网站之间又一次同步文件夹。假设在应用补丁之后，文件名称仍显示为空白。则又一次创建恢复文件夹，在新文件夹中注冊主网站。然后将备用网站与新文件夹又一次同步。

Ref:

Note 1446934.1 Some Datafiles At Standby Site Appear With NULL Name in RMAN

Note 1411883.1 RMAN-20052: invalid datafile create SCN During Resync or Backup using Recovery Catalog 11.2.0.3

8. BUG 12312133 - RMAN INCREMENTAL BACKUP WITH BLOCK CHANGE TRACKING MAY CAUSE STANDBY DB CRASH

假设在备用数据库上启用了 BCT 而且 RMAN 运行增量备份，则 CTWR 会使备用数据库出现 ORA-0600[krcccb_busy]，并崩溃。此问题影响 11.2.0.2、11.2.0.3。绕过问题的方法是禁用块更改跟踪。

症状：
在备用数据库上启用了 BCT
RMAN 运行增量备份。
CTWR会出现 ora-0600[krcccb_busy]。使备用数据库崩溃。

Errors in file /u01/app/oracle/diag/rdbms/mbcdwps/MBCDWPS1/trace/MBCDWPS1_ctwr_499736.trc:

ORA-00600: internal error code, arguments: [krcccb_busy], [], [], [], [], [], [], [], [], [], [], []

CTWR (ospid: 499736): terminating the instance due to error 487

System state dump requested by (instance=1, osid=499736 (CTWR)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/mbcdwps/MBCDWPS1/trace/MBCDWPS1_diag_1884206.trc

Workaround: 解决方法：禁用块更改跟踪。应用 patch 12312133

Ref: Note 12312133.8 Standby DB crashes with ORA-600 [krcccb_busy] /Ora-00600 [krccckp_scn] with block change tracking

9. BUG 10318078 - RMAN COREDUMPS ON EXIT : BACKUP (TO TAPE) COMPLETES SUCCESFULLY

在 11.2 中，RMAN 到磁带的备份成功完毕并退出 RMAN 时生成 core dump。

症状：
Backup（备份）成功完毕, RMAN 退出时，生成core dump（转储）。
core stack（堆栈）显示：/oracle/movt/11G/app/product/release/lib/libskgxp11.so

Workaround: 将 Oracle 可运行文件与 Media Manager API 库的静态版本号链接，而不是动态链接库

关闭全部使用此 ORACLE_HOME 的实例

% cd $ORACLE_HOME/rdbms/lib

% make -f ins_rdbms.mk ioracle LLIBMM=/usr/lib/libnwora.a

% ln -s /usr/lib/libnwora.so libobk.so

使用静态链接的库“libnwora.a”而不是动态库“libnwora.so”

Ref: Note 1296704.1 RMAN COREDUMPS ON EXIT : BACKUP (TO TAPE) COMPLETES SUCCESFULLY.

解决方式：

应用针对 Bug:10318078 的修复

Patch 11774404: TRACKING BUG FOR 10318078 FOR AIX11.2- 212 - IBM AIX on POWER Systems (64-bit)

Patch 11774413: TRACKING BUG FOR 10318078 FOR SOLARIS SPARC64

10. BUG 13602883 - BLOCK CHANGE TRACKING NOT USED FOR INCREMENTAL BACKUPS

症状：

假设在数据库（cluster_database=TRUE）运行期间意外禁用了增量备份的块更改跟踪 (BCT)、RMAN 会话或实例在上一次备份期间终止，而且 RDBMS 发行版早于 11.2.0.4，则可能命中这个 Bug。

该 Bug 影响 11.2.0.2/3（也可能影响更早的版本号），随意平台都可能发生。可是。它仅仅影响 RAC。即数据库设置了參数 cluster_database=true。

该 Bug 已在 11.2.0.4 及更高版本号中修复。

11. MML 不兼容问题：使用 Oracle 11.2 运行 RMAN备份或恢复到磁带的操作期间出现 ORA-07445 [Strcpy()+48]

不兼容的 MML 软件在使用 RMAN备份数据库时将导致 core dump。alert.log 中报告 core dump 错误 ORA-07445 [Strcpy()]。而且备份通道意外终止。

症状：

Errors in file /apps/oh/admin/PPMP/bdump/diag/rdbms/ppmp/PPMP/trace/PPMP_ora_32421.trc (incident=29135):
ORA-07445: exception encountered: core dump [strcpy()+16] [SIGSEGV] [ADDR:0x9] [PC:0x3E2B170D00] [Address not mapped to object] []

RMAN-00571: =======================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: =======================================================
RMAN-03009: failure of backup command on t1 channel at 11/18/2011 23:13:19
RMAN-10038: database session for channel t1 terminated unexpectedly

Call Stack（调用堆栈）：
__restore_rt strcpy put_string send_bprdreq bprd_get_features bsa_checkFeatureIdVxBSAValidateFeatureId xbsa_ValidateFeatureId int_StartJob sbtbackup skgfqcre ksfq_cre ksfqfcrx krbbOpenOutput krbbpc krbibpc

Ref: Note 959015.1 ORA-07445 [Strcpy()+48] during RMAN backup or restore to tape using Oracle 11.2

解决方式：

检查 MML 软件与 11.2 的兼容性。如需帮助。请联系供应商技术支持

比如：在下面网址能够找到与 Veritas netbackup 相关的具体信息

http://www.symantec.com/business/support/index?page=content&id=TECH77071

12. Bug 11694127 - RMAN DUPLICATE not honoring TIME portion of date for "UNTIL TIME" [ID 11694127.8]

症状：


    DUPLICATE 期间，当 NLS_DATE_FORMAT 不包括 TIME 规范时。
    UNTIL TIME 将被截断。

因此，构建的duplicate数据库可能会处于错误的时间点
    比如：
      假设 RMAN 复制使用命令： set until time "to_date(''Jan 27 2011 17:05:00'',''Mon DD YYYY HH24:MI:SS'')";
      alert.log 文件将显示： start until time ''JAN 27 2011 00:00:00'' using backup controlfile

    Rediscovery Notes:
     恢复期间 DUPLICATE 失败。原因是 NLS_DATE_FORMAT 不包括 TIME 部分，导致 UNTIL TIME 被截断。

    Workaround
     将 NLS_DATE_FORMAT 设置为具有时间精度的格式，然后
     使用 UNTIL TIME 运行 RMAN 复制命令。

     演示样例：
      setenv NLS_DATE_FORMAT ''DD-MON-YYYY HH24:MI:SS''
      setenv NLS_LANG ''AMERICAN_AMERICA.UTF8''
      使用 RMAN 连接到目标和 auxiliary(辅助)实例
      运行带有 UNTIL TIME 的 RMAN 复制命令

有关受影响/修复的版本号。请參阅： Note 11694127.8

11gR2 新特性 -- 待定的统计信息（Pending Statistic）

答开源创业 15 问：选协议、维权、公关、找钱・・・・・・

11gR2 新特性 -- 待定的统计信息（Pending Statistic）

11gr2 开始，可以使用下面类型的操作来收集优化器统计信息：
1. 自动发布收集的统计信息在收集操作结束以后（默认选项 publish）
2. 保存新的统计信息，并且待定（暂不发布 pending）
这个特性可以将新收集的统计信息置为待定状态，所以可以先验证新统计信息的有效性然后再发布。
可以使用下面的命令来查看是否默认发布新的统计信息。
sys@DAVID> SELECTDBMS_STATS.GET_PREFS(''PUBLISH'') PUBLISH FROM DUAL;

PUBLISH
----------------------------------------------------------------------------------------------------
TRUE

返回为 true 或者 false。True 表示新的统计信息收集后即发布，也就是说优化器会使用新的统计信息来生查询计划，False 表示收集的统计信息会被放入 USER_TAB_PENDING_STATS 和 USER_IND_PENDING_STATS，并且不会立刻被优化器使用，为待定状态。

可以使用下面的包来改变各个级别 (global,schema,table) 的默认 publish 选项。
Global
exec Dbms_stats.set_global_prefs(pname =>''PUBLISH'' ,pvalue=> ''FALSE'') ;

Schema
exec dbms_stats.set_schema_prefs(ownname => ''DEXTER'',pname=>''PUBLISH'' ,pvalue => ''TRUE'') ;

table
Exec dbms_stats.set_table_prefs(''DEXTER'', ''PUBLISH_TEST'',''PUBLISH'', ''false'');

假设你执行了上面的关于 table 的操作，那么关于 schema dexter 上 publish_test 表的统计信息收集以后就不会立刻应用于优化器上面，而是先置于 USER_TAB_PENDING_STATS 表里面为待定状态。
设置好默认的 publish 选项之后，就可以开始验证新统计信息了。
默认的优化器会使用已经发布的存放在数据字典里面的统计信息，可以通过更改初始化参数 OPTIMIZER_USE_PENDING_STATISTICS 来设定优化器使用哪一种类型的统计信息（published or pending），比如使用下面的操作来更改 session 级别的优化器统计信息来源（不要写成 alter system 了）。
alter session set optimizer_use_pending_statistics = TRUE;

这样在 session 级别内就可以使用待定的统计信息来编译 sql 语句并且生成查询计划，如果新的统计信息已经被验证，那么可以使用下面的语句发布统计信息。
Execdbms_stats.publish_pending_stats(''DEXTER'',''PUBLISH_TEST'');
如果不想使用新的统计信息，那么可以使用下面的语句去删除。
Execdbms_stats.delete_pending_stats(''DEXTER'',''PUBLISH_TEST'');

也可以使用 dbms_stats.export_pending_stats 将待定的统计信息导出，并且导入到测试系统上面运行一个全面的负载测试，以确定问题的根源。
下面是一个完整的示例：
创建测试表

_dexter@DAVID> createtable publish_test (id number , name varchar2(20) ) ;

Table created.

插入数据

_dexter@DAVID> insertinto publish_test select level , ''name'' || level from dual connect by level<= 10000 ;

10000 rows created.

_dexter@DAVID> commit ;

Commit complete.

创建索引

_dexter@DAVID> createindex idx_publish_test_id on publish_test(id) ;

Index created.

收集统计信息

_dexter@DAVID> execdbms_stats.gather_table_stats(''DEXTER'',''PUBLISH_TEST'') ;

PL/SQL procedure successfully completed.

查看一下历史统计信息（这个表中只显示已经发布过的统计信息）

_dexter@DAVID> selecth.table_name, to_char(h.STATS_UPDATE_TIME, ''yyyymmddhh24miss'')

2 from user_TAB_STATS_HISTORY h

3 where h.table_name = ''PUBLISH_TEST'';

TABLE_NAME TO_CHAR(H.STAT

------------------------------ --------------

PUBLISH_TEST 20121120161308

进行一个简单查询，可以看到，走索引的效率还是比较高的

_dexter@DAVID> set autotrace on

_dexter@DAVID> select p.id,p.name from publish_test p whereid=1 ;

ID NAME

---------- --------------------

1 name1

Execution Plan

----------------------------------------------------------

Plan hash value: 1085097009

---------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------

| 0 | SELECTSTATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |

| 1 | TABLE ACCESS BY INDEX ROWID| PUBLISH_TEST | 1 | 13 | 2 (0)| 00:00:01 |

|* 2 | INDEX RANGE SCAN | IDX_PUBLISH_TEST_ID | 1 | | 1 (0)| 00:00:01 |

---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 -access("ID"=1)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

4 consistent gets

0 physical reads

0 redo size

596 bytes sent via SQL*Net to client

524 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

设定一下表的 publish 选项

_dexter@DAVID> Exec dbms_stats.set_table_prefs(''DEXTER'',''PUBLISH_TEST'', ''PUBLISH'', ''false'');

PL/SQL procedure successfully completed.

_dexter@DAVID> selectdbms_stats.get_prefs(''PUBLISH'',''DEXTER'',''PUBLISH_TEST'') FROM DUAL ;

DBMS_STATS.GET_PREFS(''PUBLISH'',''DEXTER'',''PUBLISH_TEST'')

----------------------------------------------------------------------------------------------------

FALSE

再次向表中插入数据

_dexter@DAVID> insertinto publish_test(id,name) select 1, ''name'' || level from dual connect by level<= 10000 ;

10000 rows created.

_dexter@DAVID> commit ;

Commit complete.

在没有再次收集统计信息之前查看一下执行计划，可以看到，依旧使用旧的统计信息

_dexter@DAVID> select p.id,p.name from publish_test p whereid=1 ;

Execution Plan

----------------------------------------------------------

Plan hash value: 1085097009

---------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------

| 0 | SELECTSTATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |

| 1 | TABLE ACCESS BY INDEX ROWID|PUBLISH_TEST | 1 | 13 | 2 (0)| 00:00:01 |

|* 2 | INDEX RANGE SCAN | IDX_PUBLISH_TEST_ID | 1 | | 1 (0)| 00:00:01 |

---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 -access("ID"=1)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

1424 consistent gets

0 physical reads

2644 redo size

293416 bytes sent via SQL*Net to client

7850 bytes received via SQL*Net from client

668 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

10001 rows processed

再次收集一下统计信息，这个时候收集的统计信息不会立刻被优化器使用

_dexter@DAVID> execdbms_stats.gather_table_stats(''DEXTER'',''PUBLISH_TEST'') ;

PL/SQL procedure successfully completed.

如所料，这里还是使用旧的统计信息，依旧使用 index rangescan 代价比较高

_dexter@DAVID> select p.id,p.name from publish_test p whereid=1 ;

Execution Plan

----------------------------------------------------------

Plan hash value: 1085097009

---------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------

| 0 | SELECTSTATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |

| 1 | TABLE ACCESS BY INDEX ROWID|PUBLISH_TEST | 1 | 13 | 2 (0)| 00:00:01 |

|* 2 | INDEX RANGE SCAN | IDX_PUBLISH_TEST_ID | 1 | | 1 (0)| 00:00:01 |

---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 -access("ID"=1)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

1391 consistent gets

0 physical reads

0 redo size

293416 bytes sent via SQL*Net to client

7850 bytes received via SQL*Net from client

668 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

10001 rows processed

看一下统计信息的情况，已经发布的统计信息还是比较老的，而如下所示 pending 表里面的统计信息表示新收集的待定的统计信息

_dexter@DAVID> select ''publish'' as stat,t.NUM_ROWS,t.BLOCKS,to_char(t.LAST_ANALYZED,''yyyymmddhh24miss'') from USER_TAB_STATISTICS t where table_name=''PUBLISH_TEST''

2 union

3 select ''pending'' as stat,s.num_rows,s.blocks,to_char(s.LAST_ANALYZED,''yyyymmddhh24miss'') fromUSER_TAB_PENDING_STATS s where table_name=''PUBLISH_TEST''

4 ;

STAT NUM_ROWS BLOCKS TO_CHAR(T.LAST

------- ---------- ---------- --------------

pending 20000 50 20121120162534

publish 10000 28 20121120161308

下面我们来验证一下新的统计信息是否有助于改善 sql 语句的执行

_dexter@DAVID> alter session setoptimizer_use_pending_statistics = TRUE;

Session altered.

可以看到，使用优化器使用待定的统计信息生成的查询计划使用的是全表扫描，更加有效率

_dexter@DAVID> select p.id,p.name from publish_test p whereid=1 ;

Execution Plan

----------------------------------------------------------

Plan hash value: 3346034967

----------------------------------------------------------------------------------

----------------------------------------------------------------------------------

| 0 | SELECTSTATEMENT | | 9921 | 116K| 15 (0)| 00:00:01 |

|* 1 | TABLE ACCESS FULL| PUBLISH_TEST | 9921 | 116K| 15 (0)| 00:00:01 |

----------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 -filter("ID"=1)

Statistics

----------------------------------------------------------

148 recursive calls

0 db block gets

750 consistent gets

0 physical reads

0 redo size

261413 bytes sent via SQL*Net to client

7850 bytes received via SQL*Net from client

668 SQL*Net roundtrips to/from client

3 sorts (memory)

0 sorts (disk)

10001 rows processed

验证结束，无误，可以发布新的统计信息了

_dexter@DAVID> Execdbms_stats.publish_pending_stats(''DEXTER'',''PUBLISH_TEST'');

PL/SQL procedure successfully completed.

_dexter@DAVID> altersession set optimizer_use_pending_statistics = false;

Session altered.

可以看到 pending 的统计信息已经发布并且从 user_tab_pending_stats 表中删除，user_tab_statistics 表中的 last_analyzed 时间显示的是统计信息收集的时间

_dexter@DAVID> select ''publish'' as stat ,t.NUM_ROWS,t.BLOCKS,to_char(t.LAST_ANALYZED,''yyyymmddhh24miss'') from USER_TAB_STATISTICS t where table_name=''PUBLISH_TEST''

2 union

3 select ''pending'' as stat,s.num_rows,s.blocks,to_char(s.LAST_ANALYZED,''yyyymmddhh24miss'') fromUSER_TAB_PENDING_STATS s where table_name=''PUBLISH_TEST''

4 ;

STAT NUM_ROWS BLOCKS TO_CHAR(T.LAST

------- ---------- ---------- --------------

publish 20000 50 20121120162534

可以看到 user_tab_stats_history 表中的 stats_update_time 收集的是统计信息发布的时间

_dexter@DAVID> select h.table_name,to_char(h.STATS_UPDATE_TIME, ''yyyymmddhh24miss'')

2 from user_TAB_STATS_HISTORYh

3 where h.table_name = ''PUBLISH_TEST'';

TABLE_NAME TO_CHAR(H.STAT

------------------------------ --------------

PUBLISH_TEST 20121120161308

PUBLISH_TEST 20121120163017

好验证结束

如果已经发布了统计信息，想要恢复从前的统计信息，可以根据 user_TAB_STATS_HISTORY 中的 stats_update_time，来确定 timestamp，执行下面的操作，最后一个参数 as_of_timestamp 指的是恢复在这个时间点生效的统计信息，所以不能写 20121120161308 因为在这个时间点内它的统计信息是空的

SQL> execdbms_stats.restore_table_stats(ownname => ''DEXTER'',tabname =>''PUBLISH_TEST'',as_of_timestamp => to_date(''20121120161309'',''yyyymmddhh24miss''));

PL/SQL procedure successfully completed

_dexter@DAVID> select ''publish'' as stat,t.NUM_ROWS,t.BLOCKS,to_char(t.LAST_ANALYZED,''yyyymmddhh24miss'') from USER_TAB_STATISTICS t where table_name=''PUBLISH_TEST''

2 union

3 select ''pending'' as stat,s.num_rows,s.blocks,to_char(s.LAST_ANALYZED,''yyyymmddhh24miss'') fromUSER_TAB_PENDING_STATS s where table_name=''PUBLISH_TEST'' ;

STAT NUM_ROWS BLOCKS TO_CHAR(T.LAST

------- ---------- ---------- --------------

publish 10000 28 20121120161308

_dexter@DAVID> select h.table_name,to_char(h.STATS_UPDATE_TIME, ''yyyymmddhh24miss'')

2 from user_TAB_STATS_HISTORY h

3 where h.table_name = ''PUBLISH_TEST'';

TABLE_NAME TO_CHAR(H.STAT

------------------------------ --------------

PUBLISH_TEST 20121120161308

PUBLISH_TEST 20121120163017

PUBLISH_TEST 20121120165341

附录

dbms_stats.restore_table_stats 参数说明

-- This procedure enables the user to restore statisticsof a table as of

-- a specified timestamp (as_of_timestamp). The procedurewill restore

-- statistics of associated indexes and columns as well.If the table

-- statistics were locked at the specified timestamp theprocedure will

-- lock the statistics.

-- Note:

-- The proceduremay not restore statistics correctly if analyze interface

-- is used forcomputing/deleting statistics.

-- Old statisticsversions are not saved when SYSAUX tablespace is

-- offline, thisaffects restore functionality.

-- The proceduremay not restore statistics if the table defn is

-- changed (eg:column added/deleted, partition exchanged etc).

-- Also it willnot restore stats if the object is created after

-- the specifiedtimestamp.

-- The procedurewill not restore user defined statistics.

-- Input arguments:

-- ownname - schema of table for which statistics to berestored

-- tabname - table name

-- as_of_timestamp- statistics as of this timestamp will be restored.

-- restore_cluster_index - If the table is part of a cluster,

-- restorestatistics of the cluster index if set to TRUE.

-- force -restore statistics even if the table statistics are locked.

-- if thetable statistics were not locked at the specified

-- timestamp, it will unlock the statistics

-- no_invalidate- Do not invalide the dependent cursors if set to TRUE.

-- Theprocedure invalidates the dependent cursors immediately

-- if set toFALSE.

-- Theprocedure invalidates the dependent cursors immediately

-- if set toFALSE.

-- UseDBMS_STATS.AUTO_INVALIDATE to have oracle decide when to

-- invalidatedependend cursors. This is the default. The default

-- can bechanged using set_param procedure.

-- Exceptions:

-- ORA-20000:Object does not exist or insufficient privileges

-- ORA-20001:Invalid or inconsistent values

-- ORA-20006: Unable to restorestatistics , statistics history not available

在 CBO 时代，SQL 语句的执行计划完全依赖于在数据字典中保存的统计量信息和优化器 Optimizer 的计算公式参数。从 9i 开始到现在的 11gR2，我们说 CBO 优化器已经很成熟和完善。在通常情况下，我们的 SQL 都是可以获取到较好的执行计划以及执行效率的。

在实际工作中，我们经常会遇到执行计划低效的情况。但是这种故障根源中，绝大多数的原因在于统计量的错误或者失效。错误的统计量连带生成的就是不恰当的执行计划，以至于低效的执行过程。在 9i 时代，RBO 和 CBO 混合使用，让我们经常需要自定义的统计量收集过程。

从 10g 开始，Oracle 引入了自动收集统计量的作业，以保证数据字典中统计量正确反映数据对象状态。这在很大程度上，缓解了由于数据变化导致的统计量过期问题。但是，我们在实际工作中，还是会发现执行计划的突然变化。究其原因，就是某个时间点收集的统计量，也许不能反映数据的全貌（如中间表）。

1、统计量 Pending

在系统运维中，我们常常希望维持 SQL 执行计划的稳定。很多 DBA 和开发人员对于 hint 的依赖，很大程度上也是源于对 CBO 情况下，执行计划对于统计量过于依赖，容易形成不稳定执行计划。

那么，我们 SQL 语句执行计划的稳定性，就变成统计量的稳定性问题。更进一步，就是新的统计量更新，无论是否手动收集还是自动收集，能否促进 SQL 语句生成更高效的执行计划。

所以，一种思路是：在新的统计量收集生成时，暂时不要生效投入执行计划生成。等待最后确认统计量正确之后，再投入生产环境。

在 Oracle 11g 中，推出了统计量管理的一种新技术 ——Pending Statistic 技术，提供了这种功能。

简单的说，我们可以对一系列的数据表设置 pending 属性。设置 pending 属性之后，数据的统计量在数据字典中相当于已经锁定 Lock 住。但新统计量生成之后，不是直接替换原有的数据，而是存放在 pending 数据字典中。

在 pending 字典中的统计量，默认情况下是不会参与 SQL 执行计划的生产的。只有在进行 SQL 测试通过的时候，经过用户手工的确定，才会将其 Publish 出来，替换原有的统计量信息。

这样，就给我们运维 DBA 一种维持 执行计划稳定的思路。通过固定统计量，将新统计量 pending 的方式将原有的统计量固定，从而稳定执行计划。进而，对 pending 的统计量进行测试，只有在更好执行计划的情况下，才会替换原有的方案。

下面，我们通过实验来验证 pending 统计量的使用。

2、实验环境构建

我们选择 11gR2 进行实验。

SQL> select * from v$version;
BANNER
-----------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE   11.2.0.1.0 Production

构建数据表 T，以及对应的索引。注意，我们首先在数据表中不保存任何数据。

SQL> create table t as select * from dba_objects where 1=0;
Table created

SQL> create index idx_t_owner on t(owner);
Index created

SQL> create index idx_t_id on t(object_id);
Index created

在不显式的收集统计量的情况下，是没有对应的数据表统计量的。

SQL> select NUM_ROWS, BLOCKS EMPTY_BLOCKS, AVG_SPACE, CHAIN_CNT, AVG_ROW_LEN from user_tab_statistics where table_name=''T'';
NUM_ROWS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN
---------- ------------ ---------- ---------- -----------

SQL> select count(*) from user_tab_col_statistics where table_name=''T'';
COUNT(*)
----------
        0

SQL> select BLEVEL, LEAF_BLOCKS, DISTINCT_KEYS, CLUSTERING_FACTOR  NUM_ROWS from user_ind_statistics where index_name=''IDX_T_OWNER'';
   BLEVEL LEAF_BLOCKS DISTINCT_KEYS  NUM_ROWS
---------- ----------- ------------- ----------
        0          0            0         0

收集统计量，获取最新的数据分布状况。

SQL> exec dbms_stats.gather_table_stats(user,''T'',cascade => true);
PL/SQL procedure successfully completed

当我们修改数据内容，没有收集统计量，会存在新旧差异。

SQL> insert into t select * from dba_objects;
72202 rows inserted

SQL> commit;
Commit complete

SQL> select NUM_ROWS, BLOCKS EMPTY_BLOCKS, AVG_SPACE, CHAIN_CNT, AVG_ROW_LEN from user_tab_statistics where table_name=''T'';

NUM_ROWS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN
---------- ------------ ---------- ---------- -----------
        0           0         0         0          0

3、Pending Statistics 设置

在 11g 环境中，数据表、Schema 都存在一个统计量相关参数 PUBLISH，表示当有新统计量的时候，新统计量是否立即被 publish 出来，作为最新的统计信息使用。

该参数的默认值为 TRUE。

SQL> select dbms_stats.get_prefs(pname => ''PUBLISH'',ownname => ''SYS'',tabname => ''T'') from dual;
DBMS_STATS.GET_PREFS(PNAME=>''P
-------------------------------------------------------
TRUE

-- 设置数据表的 publish 参数取值；
SQL> exec dbms_stats.set_table_prefs(user,''T'',''PUBLISH'',''false'');
PL/SQL procedure successfully completed

SQL> select dbms_stats.get_prefs(''PUBLISH'',ownname => ''SYS'',tabname => ''T'') from dual;
DBMS_STATS.GET_PREFS(''PUBLISH''
--------------------------------------
FALSE

此时，数据表中已经包括了七万余条数据，重新收集统计量。

SQL> exec dbms_stats.gather_table_stats(user,''T'',cascade => true);
PL/SQL procedure successfully completed

SQL> select NUM_ROWS, BLOCKS EMPTY_BLOCKS, AVG_SPACE, CHAIN_CNT, AVG_ROW_LEN from user_tab_statistics where table_name=''T'';

NUM_ROWS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN
---------- ------------ ---------- ---------- -----------
        0           0         0         0          0

当我们将数据表 T 的 PUBLISH 参数修改为 false 之后，我们重新收集统计量，发现原有统计信息并没有连带的更新。

新统计量不是没有收集，而是被记录在了 pending 信息中。我们可以通过 user_ind_pending_stats 和 user_tab_pending_stats 两个视图查看被 pending 的统计量信息。

SQL> select NUM_ROWS, BLOCKS, AVG_ROW_LEN, SAMPLE_SIZE, LAST_ANALYZED from user_tab_pending_stats where table_name=''T'';

NUM_ROWS    BLOCKS AVG_ROW_LEN SAMPLE_SIZE LAST_ANALYZED
---------- ---------- ----------- ----------- -------------
    72202      1028         97      72202 2012/6/20 20:

SQL> select index_name, LEAF_BLOCKS, DISTINCT_KEYS, CLUSTERING_FACTOR,LAST_ANALYZED from user_ind_pending_stats where table_name=''T'';

INDEX_NAME                    LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR LAST_ANALYZED
------------------------------ ----------- ------------- ----------------- -------------
IDX_T_OWNER                           293           23             1884 2012/6/20 20:
IDX_T_ID                              256        72202             1665 2012/6/20 20:

4、Pending 和 SQL 执行计划

新的统计量没有被 publish 出来。那么，在一般情况下，我们的 SQL 执行计划还是依据正式被 publish 的统计量生成。

SQL> explain plan for select * from t where wner=''SYS'';
Explained

SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------
Plan hash value: 1516787156
------------------------------------------------------------------------------
| Id | Operation                  | Name       | Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
|  0 | SELECT STATEMENT           |            |    1 |  207 |    1  (0)|
|  1 | TABLE ACCESS BY INDEX ROWID| T          |    1 |  207 |    1  (0)|
|* 2 |  INDEX RANGE SCAN         | IDX_T_OWNER |    1 |      |    1  (0)|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  2 - access("OWNER"=''SYS'')

14 rows selected

实际执行情况；

SQL> select * from t where wner=''SYS'';
已选择 58799 行。

已用时间: 00: 00: 06.19

执行计划
----------------------------------------------------------
Plan hash value: 1516787156
-------------------------------------------------------------------------------
| Id | Operation                  | Name       | Rows | Bytes | Cost (%CPU)| Time    |
---------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT           |            |    1 |  207 |    1  (0)| 00:00:01 |
|  1 | TABLE ACCESS BY INDEX ROWID| T          |    1 |  207 |    1  (0)| 00:00:01 |
|* 2 |  INDEX RANGE SCAN         | IDX_T_OWNER |    1 |      |    1  (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  2 - access("OWNER"=''SYS'')

统计信息
----------------------------------------------------------
       528 recursive calls
         0 db block gets
      8962 consistent gets
      1108 physical reads
         0 redo size
   6291375 bytes sent via SQL*Net to client
     43520 bytes received via SQL*Net from client
      3921 SQL*Net roundtrips to/from client
         4 sorts (memory)
         0 sorts (disk)
     58799 rows processed

SQL>

在 sys 用户下，行数比例超过了数据表 T 的绝大多数。按照 CBO 的原则，走全表扫描可能是较好的方法。但是，由于统计量还是在空表的状态下，所以，Oracle CBO 认为 Index 路径会更好。

在 Oracle 中，存在一个参数 optimizer_use_pending_statistics，用来控制当前是否使用 pending 的统计量来生成执行计划。作为运维 DBA，可以通过这个参数暂时性的启用 pending 统计量，观察一下性能状况。再决定是否启用 publish 这些统计量。

默认情况下，该参数取值为 false。我们可以在 session 级别设置下该参数为 true。

SQL> show parameter optimizer_use_pending
NAME                                TYPE       VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_pending_statistics    boolean    FALSE

修改参数为 true 之后，Oracle CBO 在生成执行计划的时候就会使用 Pending 的统计量。

SQL> alter session set optimizer_use_pending_statistics=true;
Session altered

SQL> select value from v$parameter where name=''optimizer_use_pending_statistics'';
VALUE
------------------------------------------
TRUE

SQL> explain plan for select * from t where wner=''SYS'';
Explained

SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT |     | 58274 | 5463K|  281  (1)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T   | 58274 | 5463K|  281  (1)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  1 - filter("OWNER"=''SYS'')
13 rows selected

SQL> select * from t where wner=''SYS'';
已选择 58799 行。

已用时间: 00: 00: 04.68

执行计划
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT |     | 58274 | 5463K|  281  (1)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T   | 58274 | 5463K|  281  (1)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  1 - filter("OWNER"=''SYS'')
统计信息
----------------------------------------------------------
      7511 recursive calls
        50 db block gets
      6599 consistent gets
      1118 physical reads
         0 redo size
   2392962 bytes sent via SQL*Net to client
     43520 bytes received via SQL*Net from client
      3921 SQL*Net roundtrips to/from client
       211 sorts (memory)
         0 sorts (disk)
     58799 rows processed

果然，设置参数后，Oracle 生成了 FTS 路径，说明更新的统计量起了作用。同时，执行时间减少了近 2 秒钟，说明结果上也确实是生成了更好的执行计划。

5、Pending 统计量的后续处理

在对 pending 统计量进行合理评估之后，DBA 是可以做出删除还是发布统计量的决定的。具体操作如下：

-- 删除 pending 信息
SQL> exec dbms_stats.delete_pending_stats(user,''T'');
PL/SQL procedure successfully completed

SQL> select count(*) from user_tab_pending_stats;
COUNT(*)
----------
        0

-- 重新收集 pending 统计量
SQL> exec dbms_stats.gather_table_stats(user,''T'',cascade => true);
PL/SQL procedure successfully completed

SQL> select NUM_ROWS, BLOCKS EMPTY_BLOCKS, AVG_SPACE, CHAIN_CNT, AVG_ROW_LEN from user_tab_statistics where table_name=''T'';

NUM_ROWS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN
---------- ------------ ---------- ---------- -----------
        0           0         0         0          0

-- 发布 pending 统计量
SQL> exec dbms_stats.publish_pending_stats(user,''T'');
PL/SQL procedure successfully completed

SQL> select NUM_ROWS, BLOCKS EMPTY_BLOCKS, AVG_SPACE, CHAIN_CNT, AVG_ROW_LEN from user_tab_statistics where table_name=''T'';

NUM_ROWS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN
---------- ------------ ---------- ---------- -----------
    72202        1028         0         0         96

单发布完统计量之后，就可以在正常的情况下使用统计量生成执行计划了。

SQL> show parameter optimizer_use_pen
NAME                                TYPE       VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_pending_statistics    boolean    FALSE

SQL> alter session set optimizer_use_pending_statistics=false;
会话已更改。

已用时间: 00: 00: 00.01
SQL> select * from t where wner=''SYS'';
已选择 58799 行。

已用时间: 00: 00: 04.33
执行计划
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT |     | 58794 | 5511K|  281  (1)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T   | 58794 | 5511K|  281  (1)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  1 - filter("OWNER"=''SYS'')
统计信息
----------------------------------------------------------
       426 recursive calls
         0 db block gets
      4975 consistent gets
         0 physical reads
         0 redo size
   2392962 bytes sent via SQL*Net to client
     43520 bytes received via SQL*Net from client
      3921 SQL*Net roundtrips to/from client
         4 sorts (memory)
         0 sorts (disk)
     58799 rows processed

6、结论

在 11g 中提出的 pending statistic 的方法，可以在生产运维和稳定优化执行计划方面，给我们提供帮助。

About Me

...............................................................................................................................

● 本文作者：小麦苗，只专注于数据库的技术，更注重技术的运用

● 本文在 itpub（http://blog.itpub.net/26736162）、博客园（http://www.cnblogs.com/lhrbest）和个人微信公众号（xiaomaimiaolhr）上有同步更新

● 本文 itpub 地址：http://blog.itpub.net/26736162/abstract/1/

● 本文博客园地址：http://www.cnblogs.com/lhrbest

● 本文 pdf 版及小麦苗云盘地址：http://blog.itpub.net/26736162/viewspace-1624453/

● 数据库笔试面试题库及解答：http://blog.itpub.net/26736162/viewspace-2134706/

● QQ 群：230161599 微信群：私聊

● 联系我请加 QQ 好友 (646634621)，注明添加缘由

● 于 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成

● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解

● 版权所有，欢迎分享本文，转载请保留出处

...............................................................................................................................

拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号：xiaomaimiaolhr，扫描右边的二维码加入小麦苗的 QQ 群，学习最实用的数据库技术。

来自 “ITPUB 博客” ，链接：http://blog.itpub.net/26736162/viewspace-2140300/，如需转载，请注明出处，否则将追究法律责任。

11gR2 集群件任务角色分离（Job Role Separation）简介

在这篇文章中，我们将对 11gR2 的新特性任务角色分离（Job Role Separation）进行介绍。

在 11gR2，操作系统用户 grid 成为了集群件（GI）的 owner, 并且 ASM 成为了集群件的一部分，所以 grid 用户也成为了 ASM 磁盘的 owner。

通常有 3 种方式配置 ASM 磁盘，asmlib, 裸设备和块设备。

1. asmlib

配置 asm 磁盘的 owner 和 group。

# /etc/init.d/oracleasm configure

…..

Default user to own the driver interface : grid

Default group to own the driver interface : asmadmin

……

查看 ASM 磁盘的设置:

ls –l /dev/oracleasm/disks

brw-rw---- 1 grid asmadmin 8, 33 Jul 2 18:21 DATA

注意：从 linux 2.6 内核开始，块设备的权限和路径配置在重启之后不再被保留，除非使用 udev 创建规则文件固定。例如块设备 /dev/sda 在重启之后可能变成 /dev/sdb。如果使用 udev, 那么在添加新磁盘时，需要修改规则文件以确保设备名和权限在重启之后不发生改变。

如果使用 asmlib, 只需要确定作为 asm 磁盘的范围，asmlib 会维护磁盘的标签和权限，以便在操作系统升级后磁盘标签仍然有效。所以，asmlib 和 udev 实现的功能基本是相同的。

2. 裸设备。按照以下设置配置磁盘的 owner 和 group：

crw-rw---- 1 grid asmadmin 162, 1 Jul 18 21:40 /dev/raw/raw1

3．块设备。按照以下设置配置磁盘的 owner 和 group：

# chown grid:asmadmin /dev/rhdiskn

# chmod 660 /dev/rhdiskn

接下来解释任务角色分离中 oracle 可执行文件的权限和 group 设置。

在上面的例子中，ASM 磁盘的 group 是 asmadmin，这意味着组 asmadmin 中的成员可以对 asm 磁盘进行读写操作，当然 grid 用户也可以。而其他用户，例如 oracle，则需要通过 oracle_home/bin 下的 oracle 可执行文件访问 asm 磁盘。

这意味着 oracle 可执行文件不仅需要黏着位（stick bit），还需要是设置 group 为 asmadmin。当使用 srvctl（srvctl start database/instance）启动数据库时 oracle 会自动调用 <rdbms_home>/bin/setasmgid 设置 oracle 可执行文件的 group 为 asmadmin。

所以，如果问题出现在 oracle 不能访问 asm 磁盘，需要检查以下的内容。当然由于 oracle 可以直接访问 asm 磁盘，而不需要通过 asm 实例，所以问题的症状可能很多，甚至 ora-600 错误都可能是这个原因。

1. Asmlib 标识过的磁盘的权限和 group 设置

brw-rw---- 1 grid asmadmin 8, 49 Dec 31 12:14 DATA

2. 裸设备或者块设备的权限和 group 设置

crw-rw---- 1 grid asmadmin 162, 1 Jul 18 21:40 /dev/raw/raw1

3. RDBMS 和 GI 主目录下的 oracle 可执行文件的权限和 group 设置

rdbms_home : -rwsr-s--x 1 oracle asmadmin 188832561 Oct 30 21:22 oracle

gi_home: -rwsr-s--x 1 grid oinstall 166530359 Nov 16 14:31 oracle

注意黏着位（stick bit）的设置

最后我们对 11gR2 中安装 oracle 集群件和数据库软件中的一些 group 进行简单的介绍。

* oinstall : 这个 group 是 GI 和 RDBMS 软件的拥有者。

* dba : 这个 group 是数据库的 dba group, 对数据库具有最高权限。

* asmdba : 这个 group 是 asm 实例的 dba group, 可以启动 / 关闭实例，挂载 / 卸载 asm 磁盘组。

* asmadmin: 这个 group 是 asm 的管理员 group, 它包含 asmdba 的全部权限，同时还可以增加 / 删除 asm 磁盘，磁盘组等。

apt-get update 失败 ubuntu:Tempory failure resolving 'cn.archive.ubuntu.com ubuntu

当运行apt-get update后出现如下错误时：
E: Some index files Failed to download,they have been ignored,or old ones used instead.

可以将目录下/var/lib/apt/lists/partial/所有的文件清掉，再次运行apt-get update即可！自带源在大陆不好。

出现以下错误：

ubuntu:Tempory failure resolving ''cn.archive.ubuntu.com ubuntu

修改dns:

1,重启生效：

sudovi/etc/resolvconf/resolv.conf.d/base（这个文件默认是空的）

在里面插入：
nameserver8.8.8.8
nameserver8.8.4.4

如果有多个DNS就一行一个

修改好保存，然后执行

sudoresolvconf-u

再看/etc/resolv.conf，最下面就多了2行：

cat/etc/resolv.conf
#Dynamicresolv.conf(5)fileforglibcresolver(3)generatedbyresolvconf(8)
#DONOTEDITTHISFILEBYHAND--YOURCHANGESWILLBEOVERWRITTEN
可以看到我们的设置已经加上了，然后再ping一个域名，当时就可以解析了，无需重启。

2，重启失效：

配置文件地址 /etc/resolv.conf

使用编辑器打开

改为如下内容：
search localdomain
nameserver 202.96.128.86 希望修改成的DNS
nameserver 202.96.128.166 备用DNS

重启网络：sudo /etc/init.d/networking restart。即可

关于Ubuntu x86_64安装oracle 11gR2 XE的介绍现已完结，谢谢您的耐心阅读，如果想了解更多关于11GR2 中的常见 RMAN 问题、11gR2 新特性 -- 待定的统计信息（Pending Statistic）、11gR2 集群件任务角色分离（Job Role Separation）简介、apt-get update 失败 ubuntu:Tempory failure resolving 'cn.archive.ubuntu.com ubuntu的相关知识，请在本站寻找。

本文标签：